0

I don't know much about hashing, but I noticed a (relatively reputable) site logging me into my account by sending the url parameter "hash=longStringIAssumeisTheHashOfMyPassword".

The point of hashing passwords is so that if an attacker gained a list of all of the hashed passwords, they still wouldn't be able to get into accounts. If they are hashing my password on device, couldn't a hacker bypass the hash?

If I get a list of hash passwords, couldn't I just go to site.com/login?hash=stolenHash and login?

It's also sending my ip as a parameter, I'm not as worried about that, but it looks like anyone could type in any IP they want there.

Am I completely wrong, or is this something I should report?

edit: The hash apears to change every time I login, but I can login with old hashes multiple times.

3

This completely depends on what the server does with the provided hash. If the server simply puts that hash into its database, and then compares the hash you send to the value in the database, then yes, that would have the problems you describe.

Instead, the way this should be done is to first stretch the password locally, and then hash again on the server. "Stretching" means to apply a time-intensive key derivation function (KDF), most commonly PBKDF2. This mixes additional "salt" data into the password, and applies a hash function in a specific way to convert a human-provided password into something that is "effectively random." How that salt data is generated depends on the system. It may be random, or it may be based on some static but unique piece of information such as the user's id. There are several approaches here that provide reasonable trade-offs.

The resulting stretched value should then be sent to the server. Doing it this way ensures that the server never sees the user's actual password.

Once the server has this value, it should then apply some fast cryptographic hash function (SHA-2 most commonly) to that value and use that hash to compare to the database value. Doing it this way ensures that even if an attacker has access to the database, they cannot use that to directly login.


Based on your edit, I suspect that what they're actually sending is an encrypted password or encrypted hash. They are probably encoding something like a timestamp in the encryption. Whether this is implemented in a secure way depends highly on the details, but there is nothing inherently insecure about this approach. (The fact that old hashes are reusable is not ideal, but whether it is a significant concern depends on the rest of the system.)

As a first guess, I would assume it's insecure and badly designed, but only because this is always the working assumption when assessing a security system until proven otherwise. Without exploring the details, it's not possible to evaluate this system, but nothing you've described is incompatible with a good system.

|improve this answer|||||
1

couldn't I just go to site.com/login?hash=stolenHash and login?

Yes.

Indeed that is exactly how Microsoft's SMB implementation worked (and was vulnerable) for a very long time.

Am I completely wrong, or is this something I should report?

Neither. You have assumed that the password is being statically hashed on the client, but you haven't done any analysis to support your hypothesis. It does rather sound as if there may be vulnerabilities in the authentication system (if the password is hashed with a random salt, this would imply that it is held in clear text on the server) but at the moment you don't really know whats happenning. All the code which transforms the password is sent in the login page - you have the tools to reverse engineer it.

|improve this answer|||||
0

please report immediately those relatively reputable site owners, to secure it asap, because there is possible MITM (man in middle attack). Any attacker can sniff URL and reuse this for login into your account, also hashing password at device not a good idea, it should be hashed on server and than match with existing database password.

Note : please find out what encryption is this and try decode, may be its base64 and your password possible to decode easily.

Thanks, Jaikey

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy