Is it safe for a starting page to check password hashed on clientside?

Question

Is it safe for a starting web application to check via javascript a password against a hard-coded hashed password?

i.e.:

if (md5HashFunction(password) === '4c98fecb7fdbf0c3b848f95c92c3402e') {
    alert('you are admin');
    window.location.href=window.location.href+'/'+password;
}

Is there any way an attacker could find out the password that matches the condition/find out the admin path webpage? (www.sample.com/realpassword)

This is one more example why you don't invent your own security - it's virtually impossible for an amateur to get right. — MSalters, Apr 22 '16 at 10:31

viraptor · Accepted Answer · 2016-04-22T10:30:29.890

No, it's not safe. Client-side validation is never safe. Here are just some of the reasons:

You're publishing the hash. That means an attacker knows when the password has been changed (or hasn't) and can crack it offline rather than trying against the service itself.
MD5 should not be used for passwords anymore. It's weak, has known issues, and is trivial to crack compared to all other hashes. I can literally google for this hash and get your password (colibri) http://md5decoder.org/4c98fecb7fdbf0c3b848f95c92c3402e
You're making the password a part of URL routing. This can potentially introduce new weaknesses. For example if I can force your service to error out and dump some information about route mismatch. Or if the route matching code allows timing attacks to discover possible routes.
Password being in the URL will be saved in browser history, unlike a form password which can be controlled by the user. This allows anyone with access to your browsing history to get it.
Password is part of the service routing now, which means that people will copy/paste it and potentially expose it in other places. Maybe even places that get google indexed.
There's going to be lots more possibilities... Just don't do it.

score -1 · Answer 2 · edited May 23 '17 at 12:01

it seems checking password hashes in a starting page is a bad idea.

For this matter, more secure authentication protocols usually jump through a number of hoops in order to make sure, that such a replay attack cannot work, usually, by allowing the client to select a bunch of random bits, which are hashed along with the password, and also submitted in the clear to the server.

On the server:

generate a few bits of random
send these bits (in clear text) to the client

On the client:

generate a few random bits
concatenate password, the server's random bits and the client random bits
generate hash of the above
submit random data (in clear text) and hash to the server

As the server knows its own random information as well as the client's random bits (it got them as clear text), it can perform essentially the same transformation. This protocol makes sure, that nobody listening in this conversation can use the information later to authenticate falsely using the information recorded (unless a very weak algorithm was used...), as long as both parties generate different "noise bits" each time, the hand shake is performed.

If I were you I would read this thread twice

What you're describing is a poorly specified digest authentication. There are additional elements typically used to make it more secure. If anyone really wants to implement it, [rfc2617](https://tools.ietf.org/html/rfc2617) is mendatory reading. (and [wikipedia](https://en.wikipedia.org/wiki/Digest_access_authentication) for background) (it's still an old and not very secure mechanism) — viraptor, Apr 23 '16 at 02:00

Is it safe for a starting page to check password hashed on clientside?

2 Answers2