Tell HN: Somebody implemented something I wrote a blog about

People tend to overvalue ideas. I see this all the time in writing where people are worried someone will steal their great idea for a story. The truth of the matter is that it’s unlikely that you’ve come up with something truly new and in any event, ideas tend to breed and multiply. I will never write all the stories and novels that I have jotted down in my notebook before I die and there are more every day.

Same. I'll often share relevant ideas in comments here and elsewhere in the hope that I inspire someone to go implement something I might like but will never find the time+organisation to get around to creating!

I could be wrong, but I'm fairly sure that wasn't the case originally.

Just fyi, if something is unlicensed, then other people can only use it under fair use. You’re the copyright holder automatically upon publishing and retain all rights. If you intend to let people do anything, then you need to explicitly put it in the public domain or use an appropriate license.

It’s very unlikely they can legally do what you’re describing… but it’s up to you to enforce it.

This was posted above: https://www.isnic.is/en/site/login First time I've seen it too

My employer does it for products requiring PCI certification. Our PCI auditor recommends it even though it's not a formal requirement of PCI v3.

Correct. The blog suggests letting them know out-of-band, like via email, not in the login flow.

I have read the linked post too quickly before sending my initial comment. Indeed, a back-channel notification to the legitimate account owner is probably a good idea.

On the other hand, disclosing to the attacker that they got the password right is not acceptable.

Or the login process should just go ahead and ask the 2FA either way - and just fail you in the end without explaining why. And then notify only behind the scenes via mail that the password was correct but the 2fa wrong. That would be the way to handle it. I'd receive such notifications from time to time - I mix up the 2FA accounts sometimes, other times I'm slow typing and it expires - but I can live with that little extra email.

tl;dr: The code should verify the user's second factor before the user's password.

Consider this, scenario A:

1. When attacker enters a username and bad password. then they receive a bad password error.

2. When attacker enters a username and good password, then they receive a 2FA prompt.

And then scenario B:

1. When attacker enters a username and bad password, then they receive a 2FA prompt.

2. When attacker enters a username and good password, then they receive a 2FA prompt.

In scenario A, the website leaks password validity to the attacker. In the case of a brute force attack, the attacker can use the 2FA prompt as a signal that they found a good password. Scenario B does not leak that information, because the second factor was wrong or missing.

More concretely, this pseudo-code:

    if user.authenticate_with_password(password)
      if user.authenticate_with_second_factor(code)
        # ...
      else
        raise InvalidSecondFactorError
      end
    else
      raise InvalidPasswordError
    end

Should instead be this pseudo-code:

    if user.authenticate_with_second_factor(code)
      if user.authenticate_with_password(password)
        # ...
      else
        raise InvalidPasswordError
      end
    else
      raise InvalidSecondFactorError
    end

Hope that makes sense. :)

If you input a username and wrong password, in some cases, the service won't prompt you for your 2FA code.

If you input the right username and password, it will then go forward in the flow and prompt you for the 2FA.

I believe parent comment is suggesting the system should prompt for 2FA even if the password was incorrect, so that you can't infer whether you guessed the correct password without also compromising the 2FA method.

This only matters if you re-use passwords, though.

This is the real leakage. I guess we solve it by sending an email to the address to continue account creation.

Your login form doesn't need to display an empty second factor input. Your server can send back a specific error code on first login attempt that can be used by the UI to prompt for the user's second factor, whatever that may be (or even give a choice, in the case of multiple second factor types).

For example, given this /login request to our server:

    POST /login
    Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=

Depending on the user's second factor, the server could send back a response like this:

    { "error": { "code": "TOTP_REQUIRED" } }

Then, depending on the error code, our UI could prompt for the second factor and we could send a new /login request:

    POST /login
    Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=
    { "totp": "123456" }

This flow can work for any type of second factor, not just TOTP. It also works for good and bad passwords, and doesn't leak any information (well, other than the fact the user exists, but that road introduces a lot of other UX issues.)

> Now, if someone fails the password check, clearly the user's current password is still secure so leaking that the attempted password was wrong to an attacker is not particularly helpful to them.

Maybe I misunderstand your post, but I think the parent comment is talking about leaking whether a password is correct and not whether it's wrong. (If I did misread your comment, apologies in advance and disregard the rest.)

The parent comment is basically suggesting that if there are two possibilities for password entry with two different experiences, then we may be telling hackers that passwords are correct, too.

Scenario 1: Password is incorrect and user sees "Oops, wrong password!" message.

Scenario 2: Password is correct and user sees 2FA prompt.

You are correct in that Scenario 1 doesn't help the hacker -- but Scenario 2 does! It tells them that the for username jabbany@email.com, password hunter2 is a valid password. Even if they do hit the 2FA surprise and can't crack it, they can now take jabbany@email.com to any other website and try password hunter2, and any other site using the same credentials that is NOT secured by 2FA is now compromised!

There's also username leakage here. Imagine you had an OnlyFans account, and your coworkers or friends or parents were to put jabbany@email.com into it, and it simply said "Oops, wrong password" instead of something more generic. Now they know you have an OnlyFans account -- which, depending on your relationships, could be problematic, regardless of whether they actually accessed the account.

So to the parent comment's point, it is amazing how often credential leakage happens. And to OOP's point, we should go to 2FA every time, whether the credentials are correct or not. And the error messages should (generally) be more vague than specific, so as not to leak info unintentionally.

Does that make sense? I'm not sure I explained it very well, but I think the parent and I are making a different point than yours -- which is also a valid point, just not what we were talking about.

Sure. But I’d argue that nobody should be using SMS 2FA. There are more secure, and cheaper, methods.

The stupid thing is that it already is async and not locking up like it was in the very old days op refers to. They were just so clever as to add a timeout after which that dialog closes, regardless of whether the page actually finished loading. So on a slower page you end up with the popup disappearing while the page is still (mostly) blank and you don't know yet whether the credentials were correct.

I think just clicking in a blank spot (or the text fields) in that dialog stops the timeout, but it's one of these things I'm not actually sure about and it's almost like a cargo cult kind of ritual...

I find that it usually sticks around long enough. But I agree that it should stay open at least until I interact with something else.

On the bright side it just collapses into a "key" icon in the URL bar that you can click to open it back up and save the password.

It’s like that Teams pop up that informs you that a colleague started a meeting, the one that always disappears after you finish typing your sentence and start to move your mouse towards it.

The most amusing (for me) behaviour is what OR I need to press Csncel everytime ( my preffered bahaviour, honestly, I don't save passwords) OR never see the dialog again (I'm totally okay with saving the pass for some LAN devices which would be never acessible from the net ever - but I can't)

This is great! Imagine how many people had no idea how to get something like that fixed yet noticed the bug.

Do you happen to have a link to the proposal I can see and share with a class? I'm teaching a few lectures about some "weird" stuff this semester, and this would be a great example.

Even MacOS Safari does this. I don't know whether the latest update fixed it though.

I also suggested it but their iOS app still does not have it. Really annoying with >20 totp tokens.

its my default browser now. It still great!

Are you sure tabbed browsing was Opera? I mean, Mozilla browser (predating Firefox) had it in 1998.

Spatial navigation is a feature I really do miss. I don't think any other browser supports this. It made keyboard-based browsing possible without resorting to stuff like hit-a-hint. You could just hit Shift+Arrow Key (which I mapped to the home row) and select a the nearest link (or anything interactive) in that direction. I think it worked in a visual fashion so order in the DOM didn't matter at all. It behaves exactly like one would expect.

Something I really miss from Opera is that the content of every page you visited was saved and stored for search! This helped me so often to find pages that I had visited, and remembered a few words from, but didn't bookmark or save otherwise. No idea why browsers today did not copy this feature.

Text reflow on mobile browsers. I still miss that feature and much prefer that with desktop mode vs crappy mobile mode sites.

As a general privacy rule I like stripping this by default. Couldn't you just zip up some images to retain this?

I think the EXIF data is removed because, for the vast majority of people that don't think to remove it, it's a safety risk. Posting a picture of your house? Your kid arriving at their first day of school? Some other location you'd rather a bad person not have info on? Most people don't think to remove that data before posting (and sometimes post directly from their phone camera?)... removing that data removes a lot of risk for them. Leaving it in is only considered a small benefit to a smaller subset of people (comparatively)

Oh no this is a bad idea. There's a bunch of data (including location!) that is often included in EXIF.

People would doxx the hell out of themselves without knowing it all the time if you did that.

Sadly, 1Password seems to just get worse and worse in terms of usability with each release. The latest incarnation has so many little annoyances that makes me seriously consider switching. The one thing it's got going for it that really is kind of a killer feature for me is SSH key handling. It's super nice being able to sign your commits with Touch ID. Everything else is meh at best.

They may have come full circle but I certainly haven’t.

Any person/company/thing that uses 1Password needs to take a look around. Bitwarden is where it is at.

I just did a whole test because I missed the fact that you said 1Password 8. I'm still on 1Password 7: https://imgur.com/a/WpeffJE

I understand it not working on a Roku but why couldn’t you use an android pdf reader?

You could always open the pdf on your phone and cast your phone screen.

I usually cast them from my ipad to the tv.

My ipad may be a very expensive PDF reader but it's bloody good at it.

I think the email is just a failure notification, not a second factor.

I tend to see a lot more negativity than positivity as the default response so I like this thread.

That's pretty rare in our scenario, also it still would apply to the original post ?