javascript - If hashed password is in DB can villain use that hashed password in input box in login -

i read this module (bcrypt) use login, password saving stuff. understanding, main problem solves if hacker gets access database , don't hash password hacker can copy , paste username , password , access account. module provides methods compare hashed string , password sent through req.body.password.

my understanding of hashing takes text , create long string of random characters. in apps string stored in mongodb password field how prevent hackers copying , pasting random string input box , login that? i'm not seeing point of hashing.

primer

ok, let's first see happens (under optimal circumstances, though simplified):

1. a user creates new password.
2. your application hashes password , persists hashed password further reading
3. if user logs in, application takes password provided user, runs through bcrypt, hashes password , hashed password compared stored password. if match, password provided via login same provided during password creation – thing need know.

so, having clear, have @ different attack scenarios.

the attacker gained read access database

ok, attacker got read access database. bad enough. personal data leaked. actually, can copy data. let's set aside , have @ passwords. attacker might see this

username    password admin       $2a$04$acauvljoravazzj6yx7k2eefut9phvvgr.ahz4xlzb9292u4bv9sm jdoe        $2a$04$ctugyhixagwdtu90xflsi.g2fquj/p4nvyw2tp3hsceugs5mpmr.e 

now, hash functions considered cryptographically secure if, , if, brute force easiest way calculate input data hash value. hash sizes , computing power of today, you'd need very long time calculate passwords hashes.

following procedure described above, while our attacker has read access database, can not take hash value , paste password – application take hash, hash again , subsequent check matching fail. benefits?

1. during normal operations, admin unable read password user chose. people tend use password on multiple instances. know should not, happens. admins know password chose? ;) how less attacker?
2. since attacker unable log in acquiring hash values, can not do on behalf of legitimate user, example buy something.
3. the attacker have put considerable resources if wanted brute force hash values in order obtain clear text passwords. give impression: assuming can 65536 hashes/s, have 2²³² possibilities, need ~ 2.18*10⁶² years brute force hash, 1.59*10⁵² times age of universe. lot of cores doing parallel processing (say whole planetary system converted computers), take very, very, long.
4. the attacker unable identify identical passwords, since bcrypt, same input data not produce same hash value – pretty advanced hash algorithm. the 2 hashed above created same input. works because every hash contains own (pseudo-randomly generated, iirc) salt. force attacker brute force attack on each found salt value identify identical values or clear text values.

so, hashing, have made impossible attacker got read access obtain information passwords seeing hash values (other seem bcrypt hash values).

the attacker gained write access database

ok, pwned. attacker gained write access. can wreak havoc on application, copy data , delete afterwards. hope have backup current , working.

now can set new bcrypt hash "admin" , "jdoe" , can users can do. doh!

but let's can not do: read access, can not calculate clear text password given hash. there no risk attacker gains access user's maskbook, gibber or instanonsense accounts, when user used same password within application.

conclusion

with storing bcrypt password hashes, have several advantages:

1. the password hidden admins
2. even when attacker obtains hash value, can not calculate clear text password easily
3. an attacker can not make deductions on identical passwords, since each input value produce different hash value, same input. he'd have brute force each salt value. see above.
4. when attacker gains read access, can not gain access application.

hope makes advantages of storing hashed passwords clear.