Basically I have an SQL table with 3 values, username, password, and a cookie.
dog - cat - a8bfc7ec7a2b0ba10977fddd59fc403d
On login it checks if the username and password match, then it generates a random md5 hash, inserts it into the database then sets it as a cookie for the user.
Once using the site it will check if the cookie matches up with any in the database to verify they are logged in.
How secure is this system?
If I understand correctly, you are using a random md5 just as an ID to identify the client between requests without using his password. This is similar to a session cookie and will have similar security issues.
If you rely only on this cookie, anyone who steal the cookie will steal the user's account. You could extend the verification by fingerprinting the user, checking the user-agent and anything else that is unlikely to change between requests. Note that the IP may change. You could also still ask for the user's password before important actions, such as changing the user's email or password.
Note that it's not very difficult to access the user's cookies, even a browser extension can do it.
Related
I have a website which clients can log in to. Their username, encrypted password and some additional info is stored in an SQL database on the server. I am setting up a cookie to remenber the user for some days.
I read everywhere I should not save the username and password in the cookie for security reasons. I have to say I am not sure to see why. The cookie is stored on client side right? Thus it is his username and password he is able to see, what is unsafe in that?
Anyway I pretty sure there are good reasons and it is just I cannot see it, I read the solution is to do that:
hash and encrypt the password
store the login information to a file on the server
give the file a unique name
store the name to a cookie
each time you receive the cookie with the correct file name, look up the file and retrieve the login information.
So I should generate a unique ID to store in my database and associate it with the user.
How can I achieve that?
You don't need to store the username and the password. You could instead store a session key (saved in database) with an expiration date.
If you store username and password locally that is not a huge problem if the user is at home, but what if the user is not at home ? What if the user is not on his own computer ?
Even encrypted, some "bad guys" could get it.
The problem is that the user can change the cookie value. So he can set the username to someone else's name.
Instead of putting the username in the cookie, put the unique filename in the cookie. This is essentially how PHP sessions work -- they put all the session data in a file, and set a PHPSESSID cookie with the name of the file.
should not save the username and password in the cookie...not sure to see why
Because the user may not be in exclusive control of the client - e.g. a public access terminal, or even with a personal computer, this extends the attack surface for malware. The longer lifetime of the entity compared with a session identifier increases the attack surface too.
And if it's not properly encrypted and re-validated then the user can easily change the data to that of someone else.
As to the remainder....
give the file a unique name
File? What file? You are trying to implement a surrogate authentication token. The specifics of how you do that depend on the programming language and the policy you want to implement. Should the system allow for the user to store tokens on multiple machines (which implies multiple concurrent values)? Should it be strongly tied to the machine it was initially assigned to (in which case how do you establish the identity? Using the IP address or user agent has limitations)?
Generally you should store the mapping between the token and the account (and additional meta data such as machine identity and expiry) on the server.
I'm building a web application that accesses a private API. The API that I'm consuming uses HTTP Basic Authentication over TLS. My client has requested a "remember me" functionality for the web app so that users can maintain persistent authentication on a given device.
My quick-and-dirty solution is to store the Authorization header in localStorage after it has been validated. Of course, given unmitigated access to a user's device, anybody who is worth their weight in salt could copy the auth header from localStorage and decode it to retrieve the user's login/password combo.
Aside from total device compromise, are there any other security implications from storing this type of sensitive data in localStorage? Is localStorage acceptable as a store for sensitive data such as passwords? If not, how would you persist such data on a user's device beyond an individual browser session?
(I wish everybody could just use his or her private key...passwords are so 90s)
EDIT After reading HTML5 localStorage security it seems clear that storage of sensitive data in localStorage in general is a bad idea, but what better option is there for authentication persistence in this case?
I think it's a bad idea to store something related to the login or the password on the user's side.
But once an user has logged in, you can store a random string (a random hash for example) on the user's side and in your database. When the user get back, you can compare the two and if they are identical, you can log in the user. And you can ask the user to enter his password for sensitive actions (change password or login, etc.). So even if the hash is stolen, no one will be able to get the full access to this account.
Edit : this concept is already used with cookies. I've never tested it with localStorage.
currently I'm working with cakephp and implementing user management in my project.
today, i came across an issue in user session.
i have generated a cookie to remember user's password in encrypted format
The cookie restores session if users session goes expired.
now i have tried transferring cookie to other browser from chrome to Mozilla
using a cookie manager plugin.
and i have found myself logged in in both browser what is the best way to prevent this.
??
You can't prevent this. However, you can reduce the problem by having a session value generated server-side when the user starts a new session, which is some hash made from
The session ID
The user agent (attacker would have to use/spoof the same client)
Possibly the IP (would only work for fixed devices, but makes it much harder for an attacker)
Now when a logged in user tries to view a page requiring you to be logged in, you can compare more details than just the session lookup.
It's not impossible to spoof, but this reduces the problem.
This hash should never be actually sent to the client, just kept in the session information server-side.
Sorry for the generic title. I'm playing around with Mozilla's Persona at the moment. I'm using Express.js with the express-persona middleware so setting everything up was incredibly simple. The client-side part is easy too, but I'm having a hard time understanding one particular part of the documentation. It says:
loggedInUser: The email address of the user currently logged into your
site from this computer, or null if noone is logged in. For example,
you might examine the browser's cookies to determine who is signed in.
[...] Persona will compare the email address you've passed into
loggedInUser with its own knowledge of whether a user is currently
logged in, and who they are. If these don't match, it may
automatically invoke onlogin or onlogout on page load.
(Source)
express-persona sets a cookie which includes (I guess) the crypto-foo that acts as a password replacement. Am I supposed to store the email address returned by the backend in a separate cookie? That doesn't seem to be a very good idea. Maybe one of you guys knows how that's supposed to work.
You wouldn't store the email address in a cookie for Persona, any more than you'd store the username in a cookie for a password-driven login.
No, basically you do the same thing with Persona: Use a session, stored on your server, keyed from a cookie. The only difference is that your site went through the Persona auth process, instead of verifying a username + password.
The example on the page you linked to has a currentUser variable. Well, in a real web site, that variable would be filled in as a template from the server side. Do whatever you would do to support a login session, find the currently authenticated user, insert that user's email address.
I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter
I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.
Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/
The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.