Hacker News Reader

Comment by default-kramer | Hacker News Reader

> Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

I'd be much more interested what that percentage is when you only consider people who use password managers. (Which is not to imply that MFA isn't good.)

View on HN

It's hard to know who is using a password manager, but I'm sure the number is much lower, because if you're using a password manager, you are most likely smart enough to avoid phishing and some of the other attacks too (not always, but at least much more likely to be conscience about these things).

Furthermore many sites make it difficult to use a password manager because it's hard to block automated password guessers and not interfere with password managers trying to enter passwords.

My old bank used to "encrypt" your password as you typed it into the input field, on keydown it would take the character you typed and — and I'm not making this up — ROT13 it. This had the effect of making it impossible to paste anything into the input field since the script would capture your ctrl+v and replace it with the letter "i".

The icing on the cake is that when I called to complain about it, the support agent insisted in very sombre tones that it was a measure to stop keyloggers. I don't use that bank any more.

>since the script would capture your ctrl+v and replace it with the letter "i".

not an issue on firefox because you can toggle the dom.event.clipboardevents.enabled to false, and sites won't be able to hijack your pastes.

The only problem with that is that the stupid ROT13 step wouldn't be performed so the site would reject your login attempt anyway. It was one of the dumbest design decisions I've ever seen, honestly.

I'm guessing the solution would've then been to 1) disable the update event and 2) paste the ROT13'd password, either into the browser or into the input field value via the inspector.

Like you, whenever I run into sites that do weird things like that, I always find it hard to shake a bit of suspicion about how their backend is implemented (or not, depending on the case). For instance, when they start rejecting characters like "%" or "'" which have special meaning in SQL. I can't help but wonder if they're storing things in plain text.

I've run into at least two vendors I can think off the top of my head that limit what characters you can use for a password. That always makes me uneasy, and I don't buy anything from them on principle. Who knows what else they're doing that's not immediately obvious.

My guess is if you did that and pasted "password" you would get "passworq" and then your password would be wrong according to their "encryption" method.

This reminds me of the time I was trying to explain to the Verizon store rep why I was concerned that my SIM suddenly went offline, and they told me "Oh hun, nobody steals a phone number!"

Wouldn’t the solution be to just ctrl + i your password?

Trying to block automated password guessers on the client end is a fools errand anyway.

The web developers that think like this are bad at web development, and likely security. Why would anyone trying to brute force your authentication portal care about using your UI?

This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.

You'd probably mostly catch password managers and people copy-pasting passwords though. If you had per-user fingerprints also people typing on a new device...

I’m pretty sure that would be unmanageable, but love to see it tried.. Are you thinking of each character acting more like a number in a combination lock and needing to be provided to the app sequentially to be checked? I dont get how you distinguish between password managers and bots or API dictionary attacks on the same interface?

Isn't that essentially how the "I'm not a bot" captcha works though? And it seems to work pretty well.

>This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.

at that point you might as well outsource that sort of fingerprinting/behavior analysis to some service like recaptcha.

I mean, I suppose my idea is basically "build a recaptcha competitor". Otoh in house recaptcha is "better" because

- Hackers haven't spent time breaking it

- It doesn't raise the same level of privacy concerns

- You control the UI (though recaptcha3 gives you that) and have greater insight into what the score means and why

Sounds like a great way to create a huge security flaw for your users and their passwords, or a nifty method by which your attackers can DoS your site.

KISS.

I think this is actually done, and I wish I could remember the godforsaken website I encountered it on.

Reply on news.ycombinator.com