2

Why dont we use our mobile phone tho hash a password and then enter the hash on a website as the password ?

This way the password for the website would be much more complex.

Would this even increase security ?

Example

  1. Mobile phone: p4ssword --hashing--> 527fcfb9b03f2813eadd840a2ae0fb56
  2. Website: Enter '527fcfb9b03f2813eadd840a2ae0fb56' as password.
Lexu
  • 936
  • 1
  • 7
  • 14
  • 5
    It works only so long as you're the only one doing it. If it becomes popular, then every attacker would just add the hashed versions of common passwords to their dictionary. – Simon B Feb 03 '16 at 11:46
  • 3
    This reminds me of brainwallet. Instead of a truly random private key, it was derived from a password. Many people who used brainwallet had it emptied - https://en.bitcoin.it/wiki/Brainwallet – Dog eat cat world Feb 03 '16 at 12:29
  • if you are going to do that, why not generate a random string instead? – schroeder Feb 03 '16 at 19:25
  • @schroeder The user would have to remember a random string which he has no relation to. I he would remember a password and then hash this password and enter the hash on a website he only would have to remember the password and could recreat the hash from the (maybe simple) password. – Lexu Feb 08 '16 at 06:33

3 Answers3

3

I guess it depends on what the server does, but it doesn't add much protection either way (or is even worse). (Also, does the average user know how to compute a hash on mobile? Sounds quite a hassle to me.)

1. Server stores hashed password

This means client sends H = hash(password) to the server, server looks up clients hashed password H' in the DB and validates client by checking H == H'. This is really bad. Now if a DB breach happens the attacker can enter the hashed password that was stored in the DB to login. It essentially removes the point of hashing in the first place and is as if the plaintext password was stored.

2. Server stores hash of hashed password

This means client sends H = hash(password) to the server, server looks up hash of clients hashed password H' in the DB and validates client by checking H' == hash(H). Now if a DB breach happens the attacker must check if hash(hash(guess)) == recovered_hash, so the cost to the attacker is about 2x what it would be with no client-side hashing (i.e. the attacker can check passwords 50% slower which isn't much of a win). The security in this case still depends on hash being a (non-invertible) function resistant to dictionary attacks, client side hashing does little to help.

Summing up, the best thing to do is have the client enter the password in plaintext, transmit the password to the server over HTTPS, and hash the password on the server with something like bcrypt or scrypt, storing only the hash on the server. The reason your construction isn't an improvement is that the "seed" if you will does not gain any entropy and is just as easy (or not easy) to guess, you are just adding an intermediate stage.

Community
  • 1
puzzlepalace
  • 681
  • 3
  • 11
  • In situation #2,If the attacker knows the hashing algorithm, they likely know the length of the output string and limited character set used, making a brute force attack slightly simpler as only strings of that fixed length need tested. But that depends on the algorithm, of course; if the "hash" is DES crypt() with 11 chars, that's easier than something like sha512 with 6x a the length. :) – dannysauer Feb 03 '16 at 13:19
  • Well yes, in situation 2 I was assuming the hash digest size is beyond brute forcing, e.g. MD / SHA family or pbkdf / bcrypt / scrypt. If the output of the hash is able to be brute forced this is catastrophic. But if that is a case, you should also be able to find a collision efficiently for the intermediate state. – puzzlepalace Feb 03 '16 at 21:52
2

This is essentially identical to simply generating a password that isn't hashed, in security terms. Whether you use your first name for a password or the checksum of the current time doesn't matter; if the thing you send over the Internet is compared with a string directly stored in a list on the server side, then the password isn't usefully hashed.

The point of storing passwords using a hash on the server side (even if the "server" is local) is that a good hashing algorithm is one-way. So, if the list is stolen, someone who has the list can't get the passwords directly. Authentication against a hashed password requires a process be applied to the provided string, and that the results be the same. So, a stolen set of hashes only gives the output of that procedure, not the actual values which would grant authentication.

If hashing is done in the client side, though, then the list on the server side is the actual values used to authenticate. Meaning no extra work is needed to use those values to log in to the app as any user once the list is disclosed.

dannysauer
  • 678
  • 4
  • 9
1

Would this increase security? No. Any modern application already stores it's passwords hashed in the database. Whenever an authentication attempt is made, the user input is hashed and compared with whatever's in the database. Mostly this happens with a 1-way encryption (the hash cannot be decrypted back to it's raw value).

When you would create a hash on a mobile phone, there are 3 problems:

  1. You would have to save the hash of the hashed password in your database (otherwise your database would still hold the accepted version of the passwords in plain text).
  2. It is really inconvenient for a user to enter a hash that long and the chance he/she will make a typo in it is huge.
  3. The "raw" password is still typed on a (usually) internet-connected device, so it can still be intercepted.

I don't see any major security benefits by doing this. You could of course use a mobile phone in a Two-factor authentication process to increase the security of the user accounts.

Oldskool
  • 400
  • 1
  • 10