hazel 
im gonna go fucking insane

i've said it many times and i'll say it again, you need to fucking hash the password before sending it to the fucking server

doesnt help that you prevent complying clients from fucking pasting passwords in your fucking forms aAaaAAAAAAAAHHHRHHH
Mar 17 at 9:49amWeb
Show threadhazel Mar 17
and also there's no good reason to send a OTP code that's 8 (????) digits long
Show threadlighty :3 🍉Mar 17
@hazel I know this is supposed to be a callout, but thank you for the advice :3
Show threadkatlynMar 17

@hazel I know this post is a bit of a rant (and I am unaware of what the context is that brought it up, which likely contributes to my naivety), but I'm asking out of genuine curiosity since this goes against what I'm used to / have seen in the wild with regards to handling user credentials. If you hash the user's password on the client side, doesn't that just turn the hash into the user's password instead? and is still liable to any of the same MITM attacks, assuming no transport layer encryption?

there's a good chance I'm just not aware of the context this is being brought up for, but my web dev brain is just curious about the reasoning for needing to hash client side 

Show threadhazel Mar 17
@katlyn the problem i see is that if i send a cleartext password, i really dont have any good way to make sure it is hashed on the db as well. most of the time passwords will just be stored in cleartext because they hired an unpaid intern to make us a react app in two weeks and they never bothered updating it. im not too concerned about mitm attacks in this case, although they do definitely exist

maybe nothing i say makes sense, im just tired of seeing shit appsec (i've seen the horrors)