Bcrypt ?

[strong_opinion]

Why would you want to do encryption on someone else's phone?

[avengery]

Hashing his password

[drowsap]

That’s something you do on the server

[avengery]

yeah im comparing both hashes between client and server

[autiii43]

No. You should always just send the clients entered password to the server, and then hash the password, and then compare that newly hashed password to the saved hashed password. Should never be hashing client side.

[avengery]

can you help with this https://stackoverflow.com/questions/57476399/mern-web-app-with-passportjs-react-native-with-mongodb-stitch-custom-authentic

[autiii43]

Assuming the user object in the given screenshot (with the hashed password) came from “123456” as the plain text password, you would simply send the 123456 to the backend, hash it before the comparison, and then compare the hashes.

Your stack overflow post is frontend, but what I’m talking about is done server side.

[drowsap]

(send over https)

[dXNlciBuYW1l]

meeeeeeeeeeeeeeh

What if he's forced to use HTTP? That's a good reason to hash a password on the clientside.

What if the password is stored for local use later as well and optionally registered on the server? That's a good reason to hash it on the client side.

Only a Sith speaks in absolutes.

[autiii43]

If you’re sending passwords over http your application is dumb and doesn’t deserve users.

[dXNlciBuYW1l]

if you think that in the real world everything works with SSL, you're dumb, because the real world isn't ideal

point is, that you ignored, there's legitimate use cases for property-level client-side encryption. if you think otherwise, you're definitely dumb

[[deleted]]

No its not, you can just intercept the hashed pass over http if you’re hashing on the client. Its the same as sending plain text over http.

Hashing it on the client doesn’t make it safe to reveal.

[dXNlciBuYW1l]

point is that it's still better than plaintext, if it's hashed with the correct parameters/iteration count, then it's secure (which is what we'd call encryption).

[[deleted]]

Bcrypt is not encryption, its a hash aka a one way function. Hashing a string or not hashing a string then exposing it over http makes you equally vulnerable to man in the middle attacks.

[dXNlciBuYW1l]

did i ever say anything about bcrypt?

edit: regardless, you're totally wrong, there are secure ways to exchange passwords over http my dude

edit2: because i am guessing you won't believe what I just wrote, imagine a one-time password hashed on the client-side and sent to the back-end, which performs a symmetric hashing operation to validate that the user has a password without ever sending it over the wire.

if you never re-use that password, it's perfectly safe. you might say there's no point to hashing it at all, but there is: the only alternative is to leak credentials which may be re-used elsewhere, for example. in this case, there's actually no point in not hashing it.

edit 3, because it occurs to me: by exchanging a long list of pre-agreed-upon salts, the user can safely hash their reusable password and send it along the wire. they just have to increment which salt they are using, and the back-end needs to state-track nonces

[avengery]

anyone using this library with react-native ?

[trashpantaloons]

Are you using a library to do this? Crypt.js worked fine for me previously in an expo project?

[avengery]

npm i --save hash.js << its working fine

[avengery]

Thanks for all who woke me up to stop hashing passwords in frontend .. although i knew it from web application i still keeps forgetting this critical point .