News for hackers. Stuff that matters.
Re:Login Forms Over HTTPS, Please by megous on Friday January 29, 2016 @09:27AM (#10995314)
This doesn't make any sense to me. If attacker can intercept connections I'd rather he get the hash than the plaintext password. At least then actual password is still not compromised, which is good, given how many people share passwords accross services. If he can tamper with connections, there's nothing that can be done anyway.

It would be very nice if there was a feature in web browser that allowed user to opt in to something like this:

When there's a password input on a website: 1] automatically take website's domain concatenate it to plaintext password 2] generate a secure hash from 1] 3] Derive some reasonably portable text password (20-30 characters) from 2] 4] Make it so that original web page never has access to user's plaintext password 5] Submit result of 3]

Downsides:

1] Stupid websites enforcing password rules other than length (can be worked around mostly transparently). 2] Extra stupid websites limiting password length. (requires user interaction and configurable exceptions for such websites) 3] Can't login with browsers that don't implement this.

This would be very nice for people who share passwords between services. Also would make web service data leaks less valuable to attackers. User would not depend on service password handling quality and/or operator's morality.

I use different passwords for each and every service. But many people can't be bothered or don't get the risks of password sharing, so it would be at least some help to them.

Re:Login Forms Over HTTPS, Please by dh997 on Monday February 08, 2016 @09:37AM (#11058273)
Exactly. That's the risk to mitigate. Here's scrypt for js using emscripten on actual scrypt C source... the site has to provide and adjust/migrate the three factors over time to ensure a sane amount of cpu/memory is used: https://github.com/tonyg/js-scrypt

For real-world, practicality's sake, the client-side of an app would contain the PBKDF or some AA code, as opposed to the traditional, slightly-riskier "let the server handle all of it"-approach... the server still has final say on authentication and authorization, just move some of it into client-side js. There's really not much impact on FE development considering most FEs and BEs are codeveloped these days anyhow.

Btw, for web devs Two-factor auth is cheap and easy to do, Google Authenticator OTP has open source libs and requires no calls to Google to work.