0

I'm writing a web app for 100 users where I work. It is accessible on the internet, not just our intranet. Many users are unskilled users, though most use Chrome as that's the browser that's default on their laptops.

To auth with the web app this is a potential plan:

  1. User enters password
  2. Password is sent to server
  3. Password is hashed and compared with the stored hash
  4. If password is right, the browser stores the password in local storage
  5. If the users session cookie has expired, javascript posts the stored password on first view so the user doesn't have to reauthenticate

Is this a good idea?

Rich Bradshaw
  • 71,795
  • 44
  • 182
  • 241

4 Answers4

4

There is a lot of misinformation in this thread about storing passwords and localstorage vs cookies.

First thing, local storage is not any less secure than storing a user's password in a cookie. In fact, its actually more secure, because the data in local storage is never sent to the server unless explicitly asked to be sent (cookies are, which is why storing a password in them isn't secure).

That means that you can at least be sure that the password will ONLY be sent via HTTPS.

That being said, for some users the convenience of not having to log in can be very very nice. Your best bet is to use some type of client-side encryption to store the password if you want to be more secure.

Otherwise, think more about the type of information you're handling. What is more important? Usability or security? Is it banking information? What type of damage could a hacker do with the user's password?

There is no secure way to do a 'remember me' either, so the above post is completely wrong. Remember me uses a cookie, which is at best, as secure as local storage.

It comes down to preference and need. Perhaps give users the choice?

The following type of remember me can be implemented using local storage, or a cookie. What is the best way to implement "remember me" for a website?

Community
  • 1
  • 1
Jon
  • 76
  • 3
  • If you want to be sure a cookie is only sent by HTTPS, you simply use the Secure flag (https://www.owasp.org/index.php/SecureFlag). "Remember me" can offer reasonable security guarantees (if the attacker has the ability to read arbitrary cookies on the user's machines, a *lot* of things are compromised). If you only hash on the client, rather than hashing on the server, anyone who gets the server's database can log in without even having to know the real password (essentially, the hash *is* the real password, as far as the server knows). – Matthew Flaschen Oct 09 '13 at 23:24
  • Also, none of the answers said to store the password in a cookie. Rather, a cookie should be stored with a session ID. That way, if the cookie is compromised, at least they don't have the password (which is probably used for a lot of other sites in addition to this one). – Matthew Flaschen Oct 09 '13 at 23:28
2

Why bother authenticating at all if you are going to store passwords for users?

How are you going to ensure that another person using their computer cannot access your site?

Passwords are about someone sharing a secret with you, by which they tell you they are who they claim they are (authentication) - doing away with the need to re-authenticate every now and then makes the authentication scheme quite useless.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 1
    Pretty much, if you aren't going to have them check that the user knows the password, you might as well just have them using one account across the board – tsgrasser Jul 04 '10 at 07:51
2

I dont think that you should store the user's password on the client side for what you are trying to achieve . It can be done through cookies .
So suppose the user has authenticated , then maybe you could make a cookie that would reside on their machine for a couple of weeks and that would serve as their gate pass .
Storing passwords ( that too non encrypted ) is not recommended .

jmhowwala
  • 49
  • 4
2

This doesn't quite make sense. It sounds like the server doesn't support "Remember me" and you're trying to add it using the client. Why not just support it on the server? There are plenty of existing tutorials and questions on setting it up (try this search), but it basically means having a special login cookie with a randomly generated value (kept track of by the server) and a long (maybe a couple weeks, not forever) expiry. Storing the password, even hashed, opens the user up to indefinite (until the password is changed) replay attacks if someone gains access to the database.

Community
  • 1
  • 1
Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539