I am new in this world of cryptography and while reading some articles I got stuck into something that I did not understand correctly: the use of hash based on random cryptography.

On my knowledge, when I am using any program which needs authentication the program uses a Hash to save the password into the database and then when the user try to access the program, it get the password that the user insert into some textbox, use the same cryptography as used to save to hash the password and compare the insert result with the result saved in database.

How is this possible to do so if the cryptography is random?

  • $\begingroup$ Hashes used for this purpose (like SHA256) are not random. Maybe You think about random salt? Salt is a random string, but it's saved without hashing in the database. The system adds salt to the password and then hashes it. That way two people whos passwords are "123456" have two totally different hashes. $\endgroup$ – Filip Franik Apr 14 '16 at 14:59
  • $\begingroup$ Maybe is this, but it keeps me with the question, if this "salt" is random, how does the application know which salt to concatenate with the inserted password (example, both users with "123456" as password) to check if it is correct? Through the user credentials? $\endgroup$ – Luis G. Lino Apr 14 '16 at 15:05
  • $\begingroup$ Salt can be publicly known. (But every user needs a different salt value) It can be sent to the browser without compromising the security. It's just used to make the hash not trivial for decryption when someone "evil" acquires it. $\endgroup$ – Filip Franik Apr 14 '16 at 15:21

Like I said in the comment I think You mean hashing password with random salt. The salt is a random string. It's good for it to be more then 128 characters.

Usually adversarys use rainbow tables for cracking hashes. Rainbow table is pretty much a list of all possible strings and their hases. Every day powerfull computers add more strings to those tables. At the moment every password that's 8 and less characters can be cracked in matter of seconds.

Let's say Alice wants to log in into website of "Bob Bank". Her browser takes her six letter password from textbox, hashes it and sends it to the server. Evil Edvard intercepts those hases and in seconds finds the password. Doesn't sound so good.

With salt situation looks better. Bank has assigned a 128 character long string when Alice was making an account. Banks server sends this string to the browser. Evil Edvard can see it. Alices browser adds this string to the password and then hashes it. But now the hash is not of 6 character password, but of 134. Edvards rainbow tables are useless. He has to make new ones. This process can take months.

If another user will also use identical password he's salt still will be different, and hash acquired by Edvard will be different. He has to compute rainbow tables

| improve this answer | |
  • $\begingroup$ The salt usually consist of random bits, not characters. 128 bits is plenty (i.e. 16 bytes or 32 hexadecimal characters, if you must). The example of the bank is flawed; a 6 character password could still be brute forced by Edvard, who knows the salt (as you correctly pointed out). The only way to secure the password login is TLS or possibly other devices (telephone or PIN card reader that generates a one-time-password). $\endgroup$ – Maarten Bodewes Apr 14 '16 at 17:00
  • $\begingroup$ Or possibly SRP of course, OK, the only way to protect a small plaintext password or password hash over such a password is TLS, that comment was slightly over the top... $\endgroup$ – Maarten Bodewes Apr 14 '16 at 21:39

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.