I have some Ruby web apps that use OpenID for authentication and store the session in a cookie. There are a few API- and AJAX- related things that my Ruby frameworks aren't a good fit for, so I've got some node.js services. The problem is that if someone knew the URLs of my AJAX services, they'd basically be open to the public as things stand. At the moment those services do a simple check of the Origin header, but obviously that's very easy to forge.
So I want to be able to restrict access to the services running on Node (or Python, or in a non-Rack based Ruby service, or anything else) to users who are logged into the 'main' service that's run through a Rack-based web application. Are there any conventions for how this sort of thing is done? I've seen heaps of websites that will serve content and pages through example.com, and then the AJAX calls get made through api.example.com, so I'm surprised this is something I' haven't read about.
I do have an idea for how to do this, and I'd love some feedback on whether I'm missing something blindingly obvious that makes this insecure:
My Ruby web app uses OpenID for authentication and stores the session in a session cookie using Rack::Session. From looking at the Rack::Session source, my framework seems to go through this process:
generate a Marshal dump of my User object
generate a SHA1 hash of the Marshal based on a secret key
store a hex digest of the SHA1 hash in a cookie
So theoretically I could have a pre-arranged key or system for generating the key, or some message passing between frameworks through a secure channel to share the key. Then I could reverse the encryption process in any other framework that wanted to be able to verify session data. I'd have to get rid of the first step and only store JSON data or something instead of a Ruby object for cross-language compatibility, of course.
Is this considered a secure way to do things, assuming the protocols for sharing the key are appropriately secure?
What you're describing is a Message Authentication Code (MAC); in this case, it's a Hash-based MAC or HMAC. Basically, take a representation of the data you want to authenticate (make sure is coming from a certain source), append a secret key to it, and hash the whole thing. Then attach that computed hash to the message (what you just hashed minus the secret key). When the receiving party receives the message, it would take the data, append the same shared secret to it, and hash it. If that computed value is the same as the one received as part of the message, it is authentic and should be processed; if the hashes do not match, it is not from the party it should be from and should be discarded.
You may want to look at the RFC specifying the HMAC construct (just don't use the sample code as it still uses MD5; use something like SHA-256 or SHA-512 to implement your HMAC):
http://www.ietf.org/rfc/rfc2104.txt
Related
Laravel documentation says
All of Laravel's encrypted values are signed using a message authentication code (MAC) so that their underlying value can not be modified once encrypted.
In practice it means that the payload is accompanied with a little hash value. It is not a secret of how this value is generated because Laravel is an open source product. The source code says this:
// Once we get the encrypted value we'll go ahead and base64_encode the input
// vector and create the MAC for the encrypted value so we can then verify
// its authenticity. Then, we'll JSON the data into the "payload" array.
$mac = $this->hash($iv = base64_encode($iv), $value);
I personally don't see the benefit of this MAC for Laravel. Why is it there?
I mean, if we already have public key that goes along with the message and the private key hidden somewhere and openssl_encrypt as a processor. How MAC can contribute to the security? Or does it contribute to something else?
There was a security issue in Laravel 3 where you could gain access as an authenticated user. Although this seems to be more cookie related (you could somehow forge them), but MAC was added then to the cookies.
http://joncave.co.uk/2012/10/lying-to-laravel/
TLDR In the future, it would be good to see Laravel’s Crypter class have MACs built in so that all encrypted messages are verified before decryption. Examples of this type of behaviour can be seen in Zend Framework 2 and Ruby on Rails.
https://laravel3.veliovgroup.com/docs/changes#3.2.8
This is because, decryption can be done with brute force, adding a MAC means you would do nothing if it doesn't matches what it should. The exact implementation of Laravel, i don't know how much security can add, but at least makes things harder for an attacker.
as James K Polk said
A MAC uses the key, so an attacker cannot generate a correct one unless he has the key.
A MAC is needed to protect against intentional ciphertext modification.
I'm new to WebAPI and before I dive too deep, I would like to first secure the Web API application first. After days of research, I just found one approach that's straight forward.
Looking over this post How to secure an ASP.NET Web API, I understand overall how it works and it's great there is a github source for it too. (Most answers I found just describe the generic concept with no code to back it up)
My question is, how do you store this "Shared Secret Key" on the server which typically is user's password? I'm doing a ASP.NET MVC 4 app with provided membership provider and it stores the user passwords with salt.
Obviously, the salt value is randomly generated per user and it's not likely the end user knows what their salt value is.
So then, what do you do?
PS: Am I missing some well known frameworks that handle this? I know Microsoft encourages mobile app developments and want developers to create new apps, but how am I suppose to do this when I can't even build authentication for Web API easily? Sorry, just a bit frustrated.
HMAC is not typically used for authenticating users to an API. It's typically used to authenticate "trusted" systems to an API. Example: Company A wants to access Company B's protected API, but doesn't need to authenticate at the user level.
When doing HMAC, you need to have the shared secret available in clear text on both the client and server so that both systems can create the exact same request signature hash. Although you may want to store the shared secret in an encrypted format, it must be a two-way (reversible) encryption.
Ok, I'm new to web development, so I might be getting some of these terms wrong. I apologize in advance.
I am having trouble understanding the different elements of authentication. Every method seems to be advised against by someone, though not always with clear reasons. I am building a web app for a company that will have access to a database, so I would like to make sure it is secure.
So the there are three places I have seen commonly used to store information.
FormsAuthentication.SetAuthCookie(). This stores a session cookie that will exprire with the browser, and nothing sensitive is on the client. However, it can only store one value. This stackoverflow answer shows a method of storing multiple values here, but the guy who gives it says not to use it, though not why.
FormsAuthenticationTicket. I don't know where this information is stored, but it allows for a simple method of storing multiple values. Securing it, according to the documentation requires calling Encrpty() to store, and decrypt() to retrieve. This seems wasteful, but what do I know.
Session["SomeRef"] = new CustomObject(). The second answer in this question explains how to do this, but a comment to it calls it dangerous because it can be stolen. This looks like the best method to me, because the information is still stored on the server, and can store multiple values.
I cannot find any comparisons for these methods, or good explanations on the "best practice" way of storing multiple pieces of information after authenticating a user. The information is just the User's name and their userId.
Here is some further clarification to help you decide.
SetAuthCookie can be implemented in a way to store multiple values. In practice, however, you usually can't store enough to avoid a database lookup. It's best to store the user name (unique identifier) and load more information during the request. As your question suggests, you shouldn't store sensitive information on it. You should assume that all information sent in a cookie can be decrypted and read and you should take precautions that that information can't be used maliciously. All session cookies can be stolen and I'll explain why in a moment.
FormsAuthenticationTicket is the same API as SetAuthCookie but at a lower level in the Framework. With SetAuthCookie, Encrypt() and Decrypt() should be happening anyway (it's the default configuration.) It's not wasteful but use method 1 instead because it's easier.
Session has some limitations. Notably, by default it's process-dependent. That means that when the server restarts or more than one web server is involved, your session is lost and you have to authenticate again. It is the easiest to use and fastest when using the default memory session storage (InProc). You can use sql storage or a dedicated session server to overcome the process-dependency.
All three methods are considered dangerous for the same reason all cookie-based authentication systems are dangerous: because the cookie's value can be sniffed over wireless and reused to take over a session. This is known as sidejacking and it also applies to scenarios 1 and 2. The way to prevent this is to implement HTTPS. Then, the cookie transimission (and everything else) is encrypted at the network level and can't be stolen.
TLDR; Use SetAuthCookie and HTTPS
NOTE this answer has been edited several times for clarity.
I haven't had to tackle a login process before so this is new territory for me and all I seem to be finding on Google are conflicting methods of handling this process, so I was hoping someone could help clarify.
So far I have a salted SHA1 hash made from mixing username, password and my salt variable.
When the user logs in their credentials get hashed, then this hash gets sent to sql and if found comes back with a UserID (or something). So I know they are authenticated.
With that I can handle their session with session variables.
Is that right so-far?
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
I'm confused, can anyone shed some light?
Thanks in advance
You are usually better off using the authentication methods provided by your platform than creating one yourself. There are a lot of non-obvious problems that you can easily leave yourself open to. Which platform are you using? Are you using a web framework?
General purpose hashes like SHA1 are inappropriate for password hashing as they are optimised to be very quick, when you want something that is very slow. For discussion of this, see How To Safely Store A Password.
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
Hashes are designed to be one-way functions, so no, it isn't the same as putting their username and password in plain text. However if you do it that way, you'll have to create a way of letting somebody authenticate with the hash instead of their username and password, and that is the same as storing their username and password on the client (as far as you are concerned, anyway).
I like the fact that you have used salt for your hashing but I don't think it's necessary to use the username for hashing only password+salt should be enough. Specially it will inflict an overhead of rehashing if you want the option of changeable usernames for your system.
For remember me option, I don't think you should store any credentials at client side cookies. Only the session ID should be enough. If you want to make it really secure you should use client-side certificates that are issued by the server.
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
Your first login process is correct and up to todays security standards with the only exception that you may want to choose another hashing function over sha1.
Sha1 is very quick and therefore brute force attacks to crack a hash are faster. So if your hashes (database) and token (source code) get leaked, the passwords can be cracked.
One countermesure is to use a slower hashing function (see Jims answer for an article about that)
But the best of course would be not to leak your hashes in the first time.
A possibility for the remember me function is to let the user keep the session cookie for longer. For example Magento and Zend Auth does this.
This is however very ugly because you are likely to get hundrets of thousands of sessions stored on your servers, even for users that never return.
The far more elegant way is to store this information client side.
Sidenote: Of course you shouldnt put too many cookies on the client because they get transmitted with every page request. But a login cookie is a very valid case to do so. A good practice is to store the login cookie at the client side and populate the server session with data saved in a database at login which is marked in a session. This way you eliminiate continous database requests and have a good user data registry. Of course write has to be done to the database and session directly or better to the database and then somehow flushed to the application (full or incrementally).
Putting the hash in a client cookie isnt like "plaintext". However its ugly and awful and insecure on many levels.
There are some different approaches but they mostly involve some hashing again.
The most common and easy one is something like to put a cookie with user_id=john and user_token=HASH($userid.$appsecret) on the client. Or to store them as one in one cookie.
This is kinda secure but I prefer the following method:
Generate a string that holds:
userid ; user agent ; first two ip segments ; current timestamp ; your application secret token
Run it through a good hashing function and store a cookie at the users client that looks like
auth=userid;timestamp;hash-of-the-above
When the client logs in via cookie you re construct taht string from above but take the timestamp and user id from the cookie. Generate the hash and see if it matches. Then you have validated that it is the cookie you generated for that ip adress segment and this user agent at the specified time
Sidenote: first two ip segments rarely changes with dynamic isps. you can leave them away too, its for extra security.
What is the main advantage of thsi method?
The client or you can invalidate all login cookies by setting a timestamp. Only cookise that have been generated afterwards are accepted. You can also implement a timeout.
This is good if you want to "remote logout" form a public computer where you forgot to log out or something.
I think functionality is very important and with this method you dont have to keep track of single login cookies (like google does).
Hope this helps you.
You can scale this method to any level of security you like and adjust it to your needs.
your authentication is just fine. If you want to make it even more secure you could transmit the login information with a SSL encrypted connection so nobody can read what's going across the network.
The remember token is quite simple let's say you want a remember me function that is valid for 14 Days.
A stranger with no authenticated session comes to your site:
Check if there is a remember me token in a cookie
If yes, check if you can find this remember me token in your database and check if the "valid until" column is still valid (date comparison)
If you find a valid token you can set the user id and authenticate his session
If you don't find a valid token redirect the user to the login page if necessary
When the user fills out the login form and authenticates him sucessfully:
Generate a token using an appropriate hashing function. The token you hash could look like "[Timestamp]---[userpwd]" so it's (almost) definitely unique! Save the token and the date until the token is valid (+14 Days from now as example) to your database connected with the user's id. If there's an expired token, replace it because you don't need to store expired tokens.
If the user logs out by clicking the logout button or similar just delete the token record in your database and the user's cookie.
That's it!
If your platform (web server etc) supports HTTP digest authentication, i would strongly advise you to use it. It was designed by people who know more about security than either of us ever will. It doesn't send passwords over the network. It is supported by all modern web browsers, including mobile devices. If the browser has the password stored, it happens transparently during connection, giving you the 'remember me' functionality without needing to go anywhere near a cookie.
The only thing it doesn't do is let you use a nice form - the use will get a dialog box from their browser to log in.
I have a server (RoR app) sending information to a client (a Ruby Sinatra app) and I need a way for the client to be certain the data has come from my server, rather than an evil third party.
The client has to login to the server before anything will be sent back the other way so the server could reply to the login with a shared key used to sign all further responses, but then the 3rd party could capture that response and be evil.
I'd like to find some way (in Ruby, with a view to cross-platform applicability) to sign the server's response so that it can be verified without inspection of the client's code leading to forgeries. Any ideas?
UPDATE: Lets see if I can explain this better!
(I've added code to github since I wrote this question, so you can (if you like!) have a poke around : The 'client' The 'server')
The process is this: Joe Bloggs uses a bookmarklet on his mobile device. This posts the currently visited URL to sitesender.heroku.com. When sitesender.heroku.com receives that request it checks its DB to see if anyone has logged into the same account using the Target application. If they have, their IP address will have been noted and sitesender.heroku.com will make a GET request of the target app (a webserver) at that IP asking the target to lanch the bookmarked URL in the default browser.
The basic idea being that you can send a site to your main computer from your iPhone for later viewing when you find the iPhone can't cope with the page (eg. flash, screen size).
Obviously the major issue is that with an open server anyone could send a request to open 'seriouslyevilwebsite.com' to a broad range of IPs and I've unleashed a plague on the digital world. Seeing as I'm using heroku.com as a server (its an incredibly good but cloud based RoR host) I can't just test the originating IP.
As far as I understand HTTPS, for this setting I'd have to sort out certificates for every target application? I agree that I need some form of asymmetric crypto, sign the outgoing requests from sitesender.heroku.com with a private key (never distributed) and get the target to perform the same operation using the public key and test for similarity - but you've guessed correctly, I'm still slightly clueless as to how HMAC works! How is it asymmetric? Is it formulated so that performing the same HMAC operation with the private key and public key will generate the same signature? In which case - HMAC is a winner!
Thanks for your patience!
I'm not sure exactly what you mean by "freely examined, but not replicated".
In general, if you need a secure communications channel, https is your friend.
Failing that (or if it's insufficient due to some architectural issue), HMAC and asymmetric crypto is the way to go.
UPDATE: I'm not sure I understand the problem, so I will try to describe the problem I think you're trying to solve: You have clients that need to be confident that the response they are seeing is actually coming from your server.
Assuming that I'm correct and this is really the problem you're trying to solve, HTTPS solves it nicely. You install a cert on your server—you can sign it yourself, but clients won't trust it by default; for that, you need to buy one from one of the standard certificate authorities (CAs)—and then the client makes an HTTPS request to your server. HTTPS handles verifying that the provided certificate was issued for the server it's talking to. You're done.
Finally, I think there's a misunderstanding with how an HMAC works. The key principle of asymmetric crypto is to NEVER distribute your private key. With asymmetric crypto, you encrypt messages with the recipient's public key and he/she decrypts it with his/her private key. You sign messages with your private key, and he/she verifies it using your public key.