i was doing some security auditing using SSLSTRIP and the client had their password saved in a cookie, which got me thinking. So I on my account logged into YouTube and grabbed the LOGIN INFO cookie. For the benefit of my privacy i have censored part of the contents, just know that * represents one censored number. This was the contents:
decee*****d0200a8c3f**f1bd2dea**c40AAAB7IjEiOiAxLCAiMyI*IDY0MDYzMjY0MywgIjIiOiAiSjVRRFdmUDR5ZFA1VjZZZHVvNUlldz**IiwgIjUiOiA*NTAzNjAxNzY2NDY1NTM2LCAiNCI6ICJHQUlBIiwgIjciOiAxMzE0ODM1MjI5LCAiNiI6IGZhbHNlLCAiOCI6IDI5NzEwMTU4Njg1N**
I was wondering what type of hash this is, and if it is possible to decrypt? Just some plain old curiosity here, thanks for any replies or thoughts!
Youtube does not store user credentials in a cookie, that "hash" is probably just a random string used as session id, so there is no way you could "decrypt" the username/password from that string.
Cookies should never be used for storing any login credentials. That cookie probably contains some session information that is checked on server side.
Related
Our intranet system stores user data once the user logs in simply using a cookie (UserID, Name, Role..)
I was learning about JWT and tokens today and wondering is there any advantage to using that over the current way?
It seems like something might be insecure storing plain text in cookies but I also read that other web sites cannot see those cookies..
So is there any strong reason to use JWT tokens instead ?
A cookie can not be accesed by a different domain that the one which created it. This restriction is called "same-origin" policy and is a security measure to protect the local data of the site, but it does not mean that your cookie is conveniently secured
Since you are not validating the cookie content in server side, for example a user could change his UserId or Role to get access to unauthorized resources.
JWT can help you because thencontent is signed with a secret key. Any alteration to the content will break the digital signature and the server will reject the token.
An alternative is to use server session and store this data on server.
The drawback with respect to JWT is that it needs server storage.
I have an authentication form and for 'remember me' functionality, I want to use cookies which will store username and password.
Here is my question - If I want to keep a cookie for a month, will it be a good idea to store password inside cookie ? Can someone see cookie values and edit them using cookie manager etc tools ? How wise would it be to store passwords in cookies ?
Please suggest. Thanks in advance.
Cookies can easily be viewed and modified by users, for example by the Chrome extension EditThisCookie. Therefore, storing passwords in cookies is probably not a good idea.
You could encrypt the cookie using a server key that is somehow affected by the user name. You would have a base key for cookie encryption/decryption and then maybe salt it with the username stored. Crypto operations would obviously have to be performed on the server.
Probably better is storing a session key in the cookie, still encrypted to prevent theft of cookies from allowing the thief to log in. Have the session key include some information about the user-agent and whatever other info the browser supplies, maybe. Of course, you'll have to keep a table of valid session keys on the server.
I have managed to get working the authentication which i know return a token (JWT) to the client. This token has an expiration date/time so I was thinking about saving the token in a cookie so future logins were authenticated but this is probably not going to work.
I then though about saving the username and password in a cookie although i know this isn't recommended??
Currently i have a form that accepts a username and password, a successful login will provide a token which is used to access other endpoints.
The form needs to include a "Remember Me" so an automatic login can occur.
What is the best way of achieving this ?
Should i be storing the username and password in the cookie, if not how do i automatically authenticate the next time the user arrives to my site. The token that i provide is going to be expired so is there any point in even storing this ?
thanks in advance
Do not store the user name or password in the cookie. Even if the cookie is encrypted, it is better to store a credential with short expiration time like the token in a cookie than a credential like password which has more shelf life.
Even in the ASP.NET Web Forms or MVC world (Forms Authentication), typically "Remember me" works only until the time the cookie expires. "Remember me" does not mean remember me for ever and there must be a finite time period for remembering. That time can be derived from a cookie. You can put the JWT in the cookie and set the cookie's life time same as JWT, say an hour. When the user comes back to your app within that time, the cookie will not expire and the user is automatically logged in. Otherwise, they have to re-login. Do not think about storing the user name - password and systematically logging in. Let the user enter the credentials and that approach will be more secure. BTW, make sure cookie is encrypted and is an HTTP only cookie.
This mechanism will be similar to Forms Authentication. In place of the authentication ticket, you will use your JWT. Instead of FAM reading the cookie, you will need to have your own HttpModule or a message handler to do that and establish the identity for the requests.
Google's authentication coookie is good for 14 days.
http://ben.onfabrik.com/posts/dog-fooding-our-api-authentication
Looking at gmail and facebook I was wondering where do they store your password and account info when you log off and you have the function "Keep me signed in" on.
I know they store it in cookies but isnt this hackable/stealable? How safe is this system and where is this information stored?
What they save is a unique session ID that is essentially a randomly generated string. With that session ID they can store your state on the backend, i.e. logged in or not. They never store your password, encrypted or not, in a cookie.
When setting Cookiee on the server with properties(httpOnly and secure=true), does that mean it will only be secured during the communication beween server and client, but not after that?
In other words, if the value was originally in plainText -will it also be stored on the client side with plainText (after traveling with https ) -making it unsafe/vulnerable?
1) Do passwords needs to be always encrypt befors sending (even when using https)?
2) Where is httpCookiee (with secure=true) stored? and is this storage access is protected?
You probably don't want store the password.
What you need is store some "user is already authenticated" flag.
After all, you should learn about "digest access authentification". Storing hashed data is always plus.
This answer is too short, mainly bacause here is too much possibilities - and too much open questions.
Handling returning users:
You can manage (server side) an session database. in the cookie you storing only session ID. when the user authenticate itself, you're store into your server side database his status: "logged in". when he log out, you change in the DB status: "logged off".
Handling returning users has nothing with "storing passwords" in any way. You for example can authenticate users by external auth-services, like open-id, twitter, facebook etc., you're only storing his status by some session-ID or similar.
Browsers usually can store user-names/passwords, but this all time should be the user responsibility. When the user want only remeber his passwords, you should not store it in any way.
Why you want complicating your app and security mechanisms with storing encrypted passwords in cookies - what is not a correct solution - from any point of view?
Simple flow:
When an new user comes to your site - you assign him an new session-ID and store the SID into a cookie
when he login (via https) - you're store in your DB = "sessionID" -> "logged in"
when he return after a week, you can (server side) either accept his session-ID from the cookie - and from DB you can get his "logged-in" status, or, you can force login him once again (for example because of expiration)
all of the above is without any risk storing passwords in any way
1) I think so. Because even with secure flag, cookie will be stored in browser cache in plain text
2) It depends on browsers and OS. For Safari in Mac, you can find it in your ~/Library/Cookies/Cookies.plist You can see cookies with Secure flag but in plain text. It may be protected so only owner can see, but it never be good idea to have plain password anywhere in your computer
Once the secure flag is set to true, the cookie will be stored encrypted in the client even after the browser is closed. As you say it is unsafe/vulnerable.
Resp. 1)
Passwords can be encrypted before sending using Javascript, but it doesn't make much sense because https is doing the encryption for you.
Resp. 2)
The cookies are stored in the browser folder. Anybody can open the folder and see the cookies with a text editor.
The browser will handle the passwords for you. Just using a <input type="password"> and using SSL is secure enough.
And, avoid at all costs storing passwords in cookies.