So I was reading a neat article I found on /r/netsec:
https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly
One thing that really threw me for a loop is that one could flip a bit in an encrypted cookie and actually have a meaningful change in the contained data.
Making sure all traffic goes over SSL is easy enough (this isn't a question about secure transport), but this got me really thinking about message integrity and how to see if the original cookie has been tampered with. Typically I would store only the authenticated user ID in the cookie and handle all the other stuff behind my firewall. What if I could tamper with that cookie to change the user ID from the client side? The above article indicates that this is possible, as well as offering suggestions to solve this problem using preferably libsodium. I know of this library (haven't used it myself), but that leads me further down the rabbit hole in my thinking that something external to ASP's built-in security mechanisms are needed.
Regarding built-in ASP security specifically, do I need to do anything special not already implemented in the standard way of handling cookie security (letting OWIN do its thing or using FormsAuthentication.Encrypt)? If not, how is message integrity handled under the hood?
Further reading led me to this HttpSecureCookie class on code project:
http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
The above indicates using the machine key to make a cookie tamper proof, but I am unclear as to exactly HOW it makes it tamper proof. How would this prevent the malicious user from doing that bit flipping indicated in the original article to an encrypted cookie?
Simply set the forms authentication protection method to Encryption and validation.
This will protect against bitflipping attacks as the signature will not match once a bit is flipped. Validation means the message is signed.
How does validation work?
The validation algorithm can be set in web.config in the validationAlgorithm attribute of the machineKey element.
By default it uses HMACSHA256 which is a SHA-256 hash applied using the HMAC construct.
The hash signs the cookie - if the cookie value changes, the hash will no longer match. As an end user does not know the secret, they cannot change the cookie value.
e.g. Try on here to generate a SHA-256 HMAC for message foo with the secret secret.
This should give you: 773ba44693c7553d6ee20f61ea5d2757a9a4f4a44d2841ae4e95b52e4cd62db4
Note that if you change the foo to something else, the hash will be different. This is how a cookie can be protected from tampering. This cookie would be set as follows.
Set-Cookie: id=foo&hash=773ba44693c7553d6ee20f61ea5d2757a9a4f4a44d2841ae4e95b52e4cd62db4
Notice that the value is in the clear, but the hash signature prevents any tampering. This is validation only.
With the encryption and validation option foo would be encrypted first and the signature would prevent any bit flipping. This enables values to be stored in private from the end user.
If you're implementing this outside of Forms Authentication, remember though to store some type of expiry date in the cookie and include this in the signature. This date can be checked server side. Forms authentication does this by default.
Otherwise, a user could make note of a valid cookie value. Say they are given administrator access for one day and the following cookie is issued:
username=admin&hash=71b3ba92493e92ce3c60042988e9de428f44b35a6be61c8da99fa43f950d3056
The next day when the administrator access is revoked, all the user would need to do is use a cookie editor to set their cookie to the above value and they would have administrator access to the system again.
To fix this you would issue a cookie like so:
username=admin&expiry=20150508100000&hash=e38a3a003b30ceb9060165d19bb8d2a2bca6c7c531a37e888448ca417166db3a
This has the expiry date in the cookie, which is signed in the hash. Any attempt to modify the expiry date will result in a HMAC mismatch, and the user will not have access. This will prevent any tampering with the cookie expiry date or any recreation client-side.
What are our other don't-mess-with-my-cookie options if not using forms authentication?
Another method is to store a completely random, cryptographically secure generated string and set that as the cookie value. On your server, store it hashed with SHA-2 (no need for salt) and lookup this value to retrieve details about the user's session. Of course this has some more overhead. The advantage is that sessions can be killed server side by deleting the entry.
This can be done with Forms Authentication too, however you would need to implement a custom provider.
Related
i've read all the tutorials and questions asked about the subject but they contradict one another
claims(userclaims and roleclaims) are serialised into a cookie (along with custom identity user properties you specify by overriding the principle factory) but they don't get queried, they're stored in a cookie, which mean that the more claims a user have, the more data will have to round trip between the server and browser
a custom identity user property by default don't get serialised but get queried from the database, so every time you need that data it query it from the database which is more work to do on the database on each request if you frequently query for it
so which is more efficient and which is safer
for instance
IsAdmin should be a role/claim? but then if someone stole the cookie, nah nah, the cookie already contains userid/username/securitystamp, so even if it's a property, the userid on the stolen cookie would query on the custom identity user property, or is there something that will prevent this cookie from working when stolen ?
another instance
if i've 20 property for the user (first name, last name, address 1, address 2, postal code, whatever the case may be), should i simply have the user wait a bit for a bigger slower cookie to be send back and forth or should i do all the work from the db using custom identity user
but then, if i remove or add a claim to the user, would it be updated on the next request if it doesn't get queried or is the security stamp validate that this cookie is still valid ?
cause at the Task AddClaimsAsync of the userstore of efcore it only add the claim to the dbset
i apologize i know this is many questions to ask but the resources on the matter are not that good and one can easily get lost reading the identity source
Rule of thumb - put frequently added items as a claim, everything else can live in DB and be queried on demand. I.e. address 1, address 2 can't be required on every request, so keep them in the DB.
On the other hand IsAdmin (should be a role anyway) I can imagine will be checked on every request, so it should be in the cookie without having to query the db.
If you afraid of your cookies getting stolen, don't show them to anyone! set up SecurityStampValidator to do frequent checks - like every 5 minutes. This basically updates the cookie with the fresh information from your database and changes the cookie. So even if the cookie is stolen, it will only work for 5 minutes.
I don't think the two statements contradict, it depends on your configuration. The second statement mentions "by default".
You do not need to store all information in claims nor do you need all the information all the time. If you want profile information, call the server once and store the information on the client, or get it when needed only.
The same counts for authorization, in case you want to show / hide elements based on permissions. This may include a tag called "IsAdmin". Authorization should be kept close to the resource.
If your client wants to refresh the information, just call the server. Claims are not updated during each request. In general, the user has to log out and log in again. So Claims are not flexible and therefor not really suitable for properties that can change (frequently).
As for safety, it doesn't really matter that the client can alter the information, it is for display only. It doesn't change the permission in the backend.
You can consider to add something like a display name to the properties, if you are showing that in every page. You can also consider to implement caching to limit database calls. In the end it really depends on your requirements.
As for stolen cookie, you'll need to implement additional security to your server to detect suspicious behaviour. You may want to include the ip address as claim. As for the admin, add security, e.g. filter by ip address and / or use an additional code which was send by email.
I've a code to persist information in cookies about users like UserName and password.
Question is:
Its not secure to store information like that plain text in cookies.My DB store hashed passwords,so i could save those hashs in cookies and retrieve them later,but if i do that i wouldnt be able to fill password's textbox cause the hash string would be too long for it.
Is there any solutions?
You never should store Passwords in plain text, and even a hashed password can be vulnerable to reverse-lookup unless it is salted correctly. ASP.NET Forms Authentication already lets you create a Persistent authentication cookie that will allow the user to stay logged in, so you should use that instead. See the Timeout, expires, and IsPersistant properties when Creating the Forms Authentication Cookies.
Alternatively you could setup a token based authentication system, by which users get a security token after they enter their login information and this token is valid for a specified amount of time. This is how Live ID and Google Accounts work, and they usually store the tolken in a cookie that is valid for weeks at a time.
What's the best way to save user credentials in flex? Local storage doesn't seem like good place for storing confidential data, because it saves information as a plain text.
You shouldn't. Use browser cookies or a session token to identify the user to the server. For instance:
User enters username and password into a form in Flex and clicks login.
Server validates credentials. Then either in memory or in a database the server associates a random (and sufficiently secure) token with the user. Then the server returns the token to the client.
Client saves the token in either a cookie, LocalSharedObject, or just in memory. Then subsequent requests also include the token.
You can use ExternalInterface to communicate with JavaScript and store data in browser cookies.
Don't store users' name or password in cookies - create a session in the server with credentials in it, and store the session id in the browser cookies.
if your service don't support credential, then the only think you can do is save user login state in SharedObject.
You can save hash value of UserName + Random Token to SharedObject and save a copy of UserName too in SharedObject, then when application created creationComplete check wheather the hash value match with the saved user name.
the good thing about this trick is:
Password never persisted locally.
Harder to fake login because need to
match username with the hash value.
a bit hard to explain here you can check it here, source code is available for download.
User credentials are normally stored in a session variable.
You don't necessarily need to save the credentials as plain text in Local Storage; in fact, Local Storage (SharedObject) is actually serialized as AMF, so it's not plain text to begin with. Whatever medium you use to store your sensitive data, you should certainly consider using some sort of hashing or encryption techniques like SHA1 or RSA.
The difference between hashing and encryption is this:
Hashing (SHA1, MD5, etc) is a one-way encryption - in other words, it's very difficult to determine the original value of the hashed value, so what you can do is compare one hashed value to another since these hashing algorithms will always spit out the same thing.
Encryption (RSA, AES, etc) is a two-way encryption - in other words, you can determine the original value of the encrypted data, usually by using a public/private key combination
It really depends on what you're trying to do.
Hope you come right
SharedObject is a very bad place to store your password in.
Please see this:
http://livedocs.adobe.com/flex/3/html/help.html?content=security2_22.html
I'm using Forms authentication in ASP.NET MVC website and I store user account login name in AuthCookie like this:
FormsAuthentication.SetAuthCookie(account.Login, false);
I want to ask if there is a possibility that user on client side will somehow manage to change his login name in AuthCookie and thus he will be for example impersonated as someone with higher privileges and authorized to do more actions than he is normally supposed to have. Also is it better to save in this cookie user account login name or user account ID number?
The cookie will be encrypted and decrypted on the server side, so unless the user can crack the encryption key, he or she won't be able to do this.
As long as the information you store uniquely identifies your user, the choice as to what that information is is entirely down to the requirements of the particular application.
No it is not possible (well, in theory maybe but it's not feasible in practice). The value of the authentication cookie is encrypted so the user can not tamper with it. It is a good idea to store the (unique) login name in the authentication cookie, because when the IIdentity object (HttpContext.Current.User) is restored, the value that you passed to SetAuthCookie is used for the Name property of the IIdentity. The Name property will be shown if you use the LoginStatusControl, for example, so it's a good idea that the value of the Name property makes sense to the user.
Cookies are encrypted so chances for that a quite slim. But still.
More than one property approach
If you'd like to make your security even tighter you could save username as well as user ID or some other data that can't be guessed from the username. The combination of these makes it safer because if you can guess one it harder to guess others and use the correct combination of them. Ie. If you guess other user's email/username it's a bit harder to guess the same user's ID, because they're not related. So the more unrelated properties you combine the more steps it takes to get the right combination.
Logon security token approach
You could use an alternative approach described in this scenario:
User logs in.
Generate a random security logon token that can be of random length with some minimum length defined and save it against user in the data store. This is probably not a problem while it's quite common that other data is stored at logons as well like LastLogonDate info.
Use this token and save it in the cookie instead of usernames or other info.
If user logs-out, clear logon security token from the data store
User logs in again... go back to 1 and create a new token again and use it in this session.
This way it will make it safer on the long run, because this information will change on each login and if user does manually logout you can always clear that token from the store, so it won't at all be possible to inject someone else's identity. This does make it a but more complicated to use permanent cookies though but it can still be done.
This approach is not bullet proof but it provides additional security level that prevents the same attack over and over again when one account has been compromised. And also when one account is compromised it doesn't mean that others can be as well. If your security tokens are long enough it would be much harder to start a brute force attack on your site and while this kind of attack would be executed security tokens will change so it is definitely safer.
I am developing my login for my new homepage.
Now I found out, that I must save something like the userID (or another value that i can recognize my user) in the session variable of the browser.
At the moment I use INT for the userID.
So isn't it unsafe to put the userID in the session?
E.g. when I edit my session variable manual from userID 111 to userID 112, than I am logged in as a complete other user?!
Yes, it is unsafe to rely only on user ID.
You may wish to add a unique authentication token generated and remembered by the server. Also a very simple solution, but it will stop manipulating the user ID since the correct value for authentication token for the other user cannot be guessed.
You also need to submit both user ID and the corresponding authentication token at each request to be jointly validated on the server side, prior to performing the requested operation.
P.S. The above applies if you store this information in cookies which are accessible on the client side and can be manipulated. The viewstate (serialized in pages) can also be manipulated. The session collection is a server-side variable that is not available on the client so it cannot be manipulated. In this later case your user ID should be safe.
I would recommend you to implement the dual system: store the user ID and the token both in cookies and in the session and use the same validation logic (for simplicity). Should cookies be disabled you automatically fallback to using the session without changing your code.
The session variable is not stored in the browser, it is stored on the web server. (Typically anyway.)
A token indicating which session variable to use, is stored in the browser.
So storing the userid in the session variable is fine, as the user has no access to this directly.
If the user were to change the session token, to another one, that would be a problem, but they'd need to know the other token first. (I'm not sure how to do that myself.).
(You can further diminish this by using encryption, or other identifies like IPAddresses etc, it's really a case of how secure do you need your website to be?).
Also, if your site needs the user to log in, it's advisable to use https/SSL.
As Bravax says, the user does not have access to the Session variables (Cookies they do have access to).
If you are worried at all I would use a GUID instead as they are not sequential and nearly impossible to guess.
Also, have you looked at the built in stuff in .Net for authentication? Look at FormsAuthentication.
HTH,
Arry