4 ms·

You mean you're sending unhashed passwords from the client?

• mike-cardwell 14y ago
  Yes. That is the standard behaviour that nearly all sites use, and is perfectly fine.
  • repsilat 14y ago
    It's not great, though - it means that someone who hacks your server can get users' passwords a lot easier. I read a couple of weeks ago that Blizzard's games don't send the passwords to the server, they send a hash. Things are necessarily crappier on the web, of course. Edit: there's more detail at the link below. It looks clear that in at least some of their schemes they deliberately do not send the client password to the server, which sounds like a decent idea. http://www.skullsecurity.org/blog/2012/battle-net-authentication-misconceptions http://www.skullsecurity.org/blog/2012/battle-net-authentica...
    • mike-cardwell 14y ago
      If the server is hacked, then all bets are off. They can just modify the webpage if they want the un-hashed password.
      • repsilat 14y ago
        Exactly - "Things are necessarily crappier on the web, of course." I wonder, though. Could there be a "code has changed" warning from the client? I mean, authentication should be pretty damn stable, and maybe even universal. If someone does modify the page, it'd be nice to know if that change was reflected on other sites, and it'd be nice to know that someone I trust had signed off on it (cryptographically). A simple alternative is to build it into browsers. A password field could generate a salt per-domain and automatically encrypt any queries to password-fields. The server doesn't even need to know about it. You'd have to be more than a little careful building it, obviously, and you'd have to find a way to deal with passwords used on more than one site, but it could work.
    • Retric 14y ago
      Sending a hash is no different than sending a plain text password. Because the attacker has complete control at their end and can just hack a client that sends that same hash even if they don't know the original password.
      • monkeyfacebag 14y ago
        Would it not be an aid to users in cases where they are reusing the same password on multiple sites?
  • lolcraft 14y ago
    Note that getting the client to send only the hashed password is incredibly silly. If there's a leak, the hackers do not even have to crack those passwords.
• darklajid 14y ago
  How many web login forms (as an example) are doing client side hashing? The only ones I know are of the recent 'test your password in the linkedin leak' variety. How do you degrade for NoScript users? And where's the harm in that anyway (assuming TLS)?
  • michaelmior 14y ago
    Graceful degradation is pretty easy. Override the form submit handler to hash the password, set a flag that the password is hashed, empty the original password, and submit the form. Users with JS blocked will just submit the unhashed password as usual. Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful. Finally, if your server will accept hashed passwords, then getting the hash is as good as getting the password for access to your site. The only benefit is that the password is hidden so you may avoid compromising security on other sites.
    • edoloughlin 14y ago
      > Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful. I've seen this advised a lot. However, where are you going to put the per-user salt? I presume in your users table, or somewhere in your db. Does this not mean that the salts are just as likely to be hacked as the encrypted passwords? Are you not better off with either a single salt that's stored somewhere outside your db or with some other scheme for algorithmically picking a salt based on the user id?
      • sveiss 14y ago
        Salts aren't meant to be secret (or rather, no more secret than the password hashes themselves). The goal is to prevent a precomputed brute force attack. If you store straight unsalted hashes, you can precompute the hash for every likely password, store the precomputed hash -> password mappings in a nice efficient data structure (http://en.wikipedia.org/wiki/Rainbow_table http://en.wikipedia.org/wiki/Rainbow_table) and use the same precomputed tables to reverse every hash in the system with a very fast lookup. And every other system using the same unsalted hash scheme. If you have a salt, this doesn't work -- you'd need a set of precomputed tables for each salt value, which rather defeats the object of precomputation. If you take it a step further, and use a storage scheme like bcrypt or PBKDF2, not only are you protected from the precomputation attacks, but testing each password candidate takes much longer than a straight cryptographic hash -- so brute force attacks becomes much slower, too.
• JonnieCache 14y ago
  There's no real point to doing this. If you want to stop them being sniffed, send them over SSL.
• Sunlis 14y ago
  What would be the point of hashing on the client? Let's say you're using md5, and you hash the password before you send it. Chances are, that un-salted hash can be easily decrypted by any number of reverse-lookup tables around online. You can't salt the hash client side, because anyone can look at your JS and find your salting tactic. The best approach to securing information going from client to server is SSL.
  • Tyr42 14y ago
    It doesn't matter that they know your salting tactic, it still stops reverse-lookup tables with common passwords online.
    • Stefan_H 14y ago
      However any salting tactic that can be pushed and used on the client side would have a tough time using a salt that is on a per-user basis. This means that if you could salt it client side, you would need to have a static salt, which is significantly less secure than a unique salt per user.
      • udp 14y ago
        > However any salting tactic that can be pushed and used on the client side would have a tough time using a salt that is on a per-user basis. How so? Surely the client would know their username too?