Tell HN: Somebody implemented something I wrote a blog about So a while ago I wrote about how 2FA was missing a key feature: https://syslog.ravelin.com/2fa-is-missing-a-key-feature-c781... Having not had any feedback on it in a while and the idea not taking off, today somebody messaged me to say that had implemented it in their product. 1. Obviously I think this is great and more secure 2. Tell people about things you do that they played a part it- it might just make their day. |
Authentication must be evaluated and rejected only when all factors are already provided, and the rejection error should not disclose which of the factors failed.
So, with a proper login panel, my 2FA being asked does not mean that someone has my password.
Edit: this is, for example, the recommendation from PCI to separate "Multi-Step Authentication" from true "Multi-Factor Authentication": https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authe...
IMHO, the idea is not to display the info about wrong 2FA code on the login page but to use a separate channel to inform the account owner about this recent, failed login attempt. So, no info on the login page of the website (adversary would still not know that they have a good password but wrong 2FA) but e.g. an email, a text message, a push notification, etc. with this info. I would certainly like to know that someone, somewhere is trying to login to my account and that this adversary is in possession of my actual password.
It's suggesting that if the username and password are right but 2FA isn't the system should let the account owner know.
On the other hand, disclosing to the attacker that they got the password right is not acceptable.
And tangentially, while I can't be as certain about my involvement in this next part, Nickelodeon eventually uploaded a non-pixelated version of ATLA on Google Play shortly after the second time I contacted them. I still can't understand how an MS Paint quality version was uploaded in the first place, but I'm glad no one else will have to suffer through that like my brother did.
We have implemented such a system at a company I worked at, where we also took into account the credential stuffing aspect as you talk about it. It is quite challenging to ensure no information leaks (in content and in other request parameters, including response times) when users transition from the partially (un)authenticated state (username + password) towards 2FA. I have to say that security aspect is noticeable in a significant drop in credential stuffing attacks volume, but usability wise I see why this is not a popular approach :). I personally hate it, especially when 2FA that is used is TOTP.
As an aside I would recommend using U2F over OTP. This article explains some of the benefits: https://www.yubico.com/blog/otp-vs-u2f-strong-to-stronger/
Also, at the time when interactive maps had 4 arrows to click and move North, South, East and West I developed a map using Flash and MapServer where you could drag the map around with the mouse. I sent a message to Google to show my work and they replied saying it was cool. Later Google maps came out with such an interface. I'll never know if my messages had any impact but I can still dream they were my inventions :-)
Telling the user what action they are authorizing by reading back the numbers.
That “bank rep” on the phone? They are probably trying to log into your account, or withdraw cash, not verify that you are the right person to send the refund back to.
It would save a lot of problems.
Also you should be getting an alert on all your devices whenever transactions over X amount per Y time occur, and you should have an opportunity to reverse them for 24 hours (even for debit cards). Also you should be able to make windows during which time it would be longer than 24 hours, such as a Jewish holiday or when out of range. This wouldn’t apply to recurring transactions.
Recently, I got into RC cars. I was watching a YouTube video discussing the long-term issues that can arise with the particular model I own. In the video, the presenter mentions that “maybe you could 3D print something” to help address a deficiency in the vehicle design.
I just purchased a 3D printer, and thought, “Maybe I can design it myself.”
Lo and behold, someone already did, and cited the same YouTube video as their inspiration: https://www.thingiverse.com/thing:4982263
How amazing and cool is that??!
But also, the idea was kind of obvious given the way VSCode was going with its ssh plugins.
Even better, let the login pass after some incorrect credential guesses, the login goes to a random fake account.
After your password is approved before 2FA you get an email. So even if someone is somehow using the right 2FA you are aware.
Our thinking was the mosly likely outcome was someone would hit 2FA, not have the code and so close the request without even entering a bad code.
Apart from that though, it is always nice to get recognition for the stuff you put out there. I know I should do it more myself too.
It made my day when they some days later had implemented it, and emailed me back with a message that they now had implemented it.
Agree so much! I’ve met numerous people, often co-workers, who say “oh I know you I used your blog post”. Wish they’d have shot me a quick email! It’s always a nice surprise when someone reaches out to say thanks.
I thought that was silly: how do I know if I want to save the password before I've seen whether it's correct? Which I can't see until the form is submitted.
At the time I was using Opera, so I wrote in to their customer support suggesting that the prompt appear after the new page loaded. I never heard back, but a couple months later their next major release implemented exactly that behavior. A few months after that, every other browser followed suit.
I can't have been the only one bothered by the existing behavior, but given how long browsers had worked that way before I wrote in, I like to tell myself that the timing wasn't a coincidence, and that my little suggestion rippled out into a change that made a small thing better for the whole world :)
I was a tiny part in changing a tiny mostly irrelevant detail that was causing a slight inconvenience to millions of people daily. Improving humanity one bit at a time...
I also emailed the GIMP maintainers about a bug in their select color region tool in GIMP 0.99.x that made it ignore 1-pixel-wide barriers. By 1.0 it was fixed.
I was chuffed when it happened, but the internet was a smaller, chummier place back then, so we expected that kind of response more than we do today, I think.
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...
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.
But if I notice there's no feedback or implementation within a reasonable period of time, I will stop doing that ever again for that company (large, small, doesn't matter).
I refuse to waste my energy on that kind of process.
Hint hint hint!!!
After all, they can display movies, pictures, and music. PDFs, please! I'd even pay for it.
My ipad may be a very expensive PDF reader but it's bloody good at it.
I didnt do this with NYT writers or anything. Just people who clearly dont get paid/paid much to make this content but I found it useful/interesting/helpful. I think that stuff goes a long way and it really doesnt take that long to do.
I've got a tech podcast now and about once every month or two someone contacts me to say they liked it or something nice. It's a huge reason why I keep doing it. I know that sounds silly but the internet can be such a black hole. A little feedback goes a long way.
I write the blog as more of documentation for myself than something to share, but knowing that I've helped someone else is icing on the cake.
https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_A...
> When a user enters their password, but fails to authenticate using a second factor...:
> ...
> Notify the user of the failed login attempt, and encourage them to change their password if they don't recognize it.
> The notification should include the time, browser and geographic location of the login attempt.
> This should be displayed next time they login, and optionally emailed to them as well
I don't mind getting an e-mail as another form of 2fa, but that has its own issues.
I had written about (what I considered as) a vulnerability that allowed remote triggering of Bird Scooter alarms (Bird disagreed of course) on my blog [1]. I then saw this github repo linked in the comments for setting off alarms of Bird scooters [2] and reached out to the author.
The author let me know that they had used the info in my blog to script a tool for setting off Bird Scooters en masse. They then targeted the script at all the scooters in Lyon and subsequently fell asleep. When they woke up the noticed the end point was disabled... Bird had taken the action to disable the API endpoint in response of course.
Probably would've been easier to fix before someone scripted it out but it made for a fun story.
[1] https://theappanalyst.com/bird.html [2] https://github.com/pcouy/bird-whisperer
I often just want to follow up later by “adding to my library,” and it feels weird to “LOVE” it before ever hearing it. I really feel pain when I hear something terrible that I’ve already “liked” and consider the impacts to my algorithm.
Please distinguish between “like” and “save.”
A simple “plus sign” or really any other symbol that signifies “adding to a collection” without “liking” connotations (stars are out too).
One of my GitHub projects was used in a demo at Google Cloud next a while ago. the presenter was considerate enough to attribute the project to me by name during the demo and even sent me an issue just letting me know about it. That was so nice! Absolutely people should do this.
It’s very unlikely they can legally do what you’re describing… but it’s up to you to enforce it.
He went for it and offered me PDF copies of every Pocket Guide as a thank you.
If you don't mind I'm just just pasting the URL into a comment to make it a link:
https://syslog.ravelin.com/2fa-is-missing-a-key-feature-c781...
Thank you for putting this out there!
I once reverse engineered the protocol for a popular mobile game so I could write my own client for it and posted my library online for others to do the same without any expectation it'd ever get seen. Months later, I received an email from someone reverse engineering the protocol as well for different purposes. They got stuck on a particularly difficult issue I also encountered (and documented), and googling it led them to my library, saving them hours of future work.
It definitely made my day and I'm still very proud of that project because of that.
Edit: There's a second part too! I just remembered that I've posted this story on HN before, and the last time I did a dev for the game emailed me saying he looked over the code and was impressed that I was able to figure out so much despite their deliberate efforts to keep the protocol locked down. Another great day!
Did the devs try to further obfuscate the protocol after they discovered your library?
About communication piggybacked over TCP/IP without changing any one bit of packet data.
https://egbert.net/blog/articles/pulse-width-covert-channel....
Some 20 years later, a guy posted on GitHub.
https://vimist.github.io/2019/01/30/Steganographic-Packets.h...
And made my day.
Only would you have been able to claim some credits ;)
Lo and behold, while booking a journey the other day I noticed a new option for bike reservations on the route planner interface, that I'd never seen before. I haven't had opportunity to use it yet, but I hope it works well, and I'd like to think that it was my email that tipped the scales into it getting implemented (Lord knows I can't have been the first to ask for it).
You should verify a user's second factor before password.
Customer support burden when the lose the 2FA key is solved by adding a hefty fee (around €100) to recover it. No webauthn support yet though.
I think you can probably skip notifying on a single failed OTP code to avoid spamming the user when they make a typo (or are a bit too slow for TOTP) but if you were very paranoid you could also send in this situation.
We already get emails for suspicious login attempts, which isn't too useful as it's probs brute force and guessing. Too bad it requires mass adoption to become a norm.
(I don't really believe that my message really caused this to happen, it's for sure a weird coincidence to me)
Here's the plug for the project using my code: https://github.com/sinnfeinn/microweather.
All in all it is a great feeling to see your idea getting a concrete life. In a way, reporting an issue and a possible improvement to any product you care about is an essence of collaboration. Open source further helps to contribute by augmenting such effort with a skill to implement it.
When they axed the feature, all the started songs got automatically added to a new playlist called "Star" that I still use today as a workaround, I just add new songs I enjoyed to it to keep track of them, and just throw it on shuffle when I'm not in the mood for anything specific.
Spotify should totally have a save to library function but also a heart function that trains their personalized mixes for me. I’ve just stopped looking at my library for my music catalog. Every album I like goes into a “favorite albums” folder. It shooldn’t have to be this way.
I often browse spotify while listening. If I find something I haven't heard for a long time, I often want to directly listen to it, but not cut of the current track.
If there's a program with this type of functionality, lmk.
Most services today have fairly low "lockout" + "notify" thresholds on wrong passwords so brute force spraying passwords is already out of the question.
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. If, however, the password is correct, then the attacker gets hit with the 2FA surprise. Assuming the great suggestion in this post is implemented (it really should be), the attacker now is stuck--abandoning the login or trying an incorrect 2FA could all trigger notifications to the user that their password was breached [re: the "Was this login you?" prompts implemented by major services after these situations]. Attackers would need to also solve the 2FA in some reasonable period to "disarm" such an alarm.
Real users who happen to fumble once or twice are also fine, since they won't be surprised about the login confirmation as it really was 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.
1. Users who aren't using 2FA have a confusing box to leave empty.
2. SMS, Email and similar OTP codes should only be sent after the password is verified.
3. U2F requires the site to share which devices are registered which can only be done after the password is verified.
You may be able to make it work UX-wise if you separate username from auth information (such as a lot of sites do to support SSO auth). But even then it isn't clear to me if you should be leaking information about their 2FA configuration (especially their U2F device) list without a password.
For example, given this /login request to our server:
POST /login
Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=
{ "error": { "code": "TOTP_REQUIRED" } }
POST /login
Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=
{ "totp": "123456" }
the cost of sending those 2fa texts is not zero and also the idea of them is that they are ephemeral so them being tied to the successful entering of username and password and limited in time is a feature... not a bug.
Errm, could you elaborate what is the issue here?
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
if user.authenticate_with_second_factor(code)
if user.authenticate_with_password(password)
# ...
else
raise InvalidPasswordError
end
else
raise InvalidSecondFactorError
end
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.
Then moved to unicode CLDR: https://unicode-org.atlassian.net/browse/CLDR-13106
(The rest of the posts are an interesting rabbithole if you're not aware, apologies in advance)
It turned out to be a low-level bug in glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=10797
It got fixed five years later, long after I had worked around it and left the job where I found the bug.
I've been using Firefox as my main browser since 2010 and I never realized this.
Then Netscape and IE got into a war for mindshare, and part of that was to ignore MDI and splash their browser windows all over the taskbar instead, to be more visible and grab more user attention.
Tabbed browsing was never a new invention, it was just a re-implementation of what we already had by way of MDI.
According to: https://www.makeuseof.com/tag/which-browser-invented-tabs-3-...
Thousands in legal fees, chasing someone across different timezones and the sheer amount of work isn't worth it unless it's a legit business.
Copyright laws really fail for those without money.
It does leak a little information. It leaks the type of 2FA the user has configured and a list of devices for U2F (since that needs to be provided to authenticate). But that is likely acceptable.
Ferraris probably aren’t know for having sufficient cup holders.
I quit using Opera after he did not keep his promise to swim across the Atlantic in 2005: https://www.zdnet.com/article/opera-boss-starts-atlantic-swi...
Genius.
If you don't directly control how that happens they will implement it fundamentally wrongly.
But after it is finally implemented more or less correctly, everyone will agree that the idea was trivial and obvious, and they had already thought of it themselves, in exactly the form where they first encountered it, even if that is actually not quite right.
I know I can do that, it just doesn't sync when I change another list, which breaks everything.
So you’re asking for the business to implement something that makes their own users less secure so that sites that don’t provide 2fa can be more secure. Maybe it would be better for those sites to improve their own security instead of asking others to compromise theirs to help cover for someone else’s lack of effort.
The leak of the password's correctness here is ultimately not problematic as it acts as a tripwire and a surprise for the attacker. In fact the platform can take action on the user's behalf and lock logins with that password until the user confirms it was them trying to login via a separate channel (if you used Google 2FA this is what they do). It also protects accounts without 2FA because it becomes risky for the attacker to just try a password list they find. Maybe they're lucky and get in, or maybe the account has 2FA and you've just burned the password by trying it and alerting the user/platform about the compromise.
If it were the other way around with 2FA first, you would have no way of knowing your password is compromised somewhere. Even if the attacker knew the right password, the would not attempt to login unless they defeated the 2FA. Now you have no early warning system, and it becomes all-or-nothing: attacker get full access or they wait silently.
To sum it up: The login is no weaker if you put 2FA after password auth (same amount of compromises needed to get in). 2FA after password can leak password validity information for a short duration of time (on the scale of 15mins), but it also sets in motion an alarm that invalidates that password when an attack is attempted. 2FA after password also provides a tiny bit of extra protection to non-2FA accounts by letting them hide among the 2FA ones.
(Also, the original purpose of 2FA after password is to cut down costs for the platform back when SMS 2FA was the only 2FA. This is largely irrelevant today with TOTP and FIDO2 relegating SMS based authentication as the least secure option.)
I'm not concerned about someone hacking this site with the 2FA tripwire, but instead about leaking password's correctness could impact usage of that password on other sites that use the same username/password and do not have 2FA.
Imagine if I go to Amazon and put in jabbany@email.com / hunter2 and then come up against a 2FA prompt instead of a password error prompt. Okay. I have a signal that suggests that hunter2 is, in fact, your password. I bail immediately. No point in randomly trying to guess a 2FA auth code.
Now I go to Walmart.com and put in jabbany@email.com / hunter2, and it works -- because there's no 2FA on Walmart.com and you re-used the password!
In this scenario, 2FA doesn't actually stop the hacker from compromising your accounts! It only stops this account with 2FA -- in that sense, you are 100% correct! -- but perhaps only temporarily, because they may be able to compromise other accounts that would allow them to eventually reset your 2FA tokens and get through.
If Amazon were to tell me "hey, someone failed the 2FA auth attempt, you should you change your password," then that's one thing. But we both know most sites don't do that.
This does not make reuse more dangerous either. An attacker with a leaked password list will try them against known sites anyways. If they wanted to try a leaked password against Walmart they'd have done it regardless of the 2FA signal. There's no reason to assume that if a password is (in)correct on one site that it would (not) be on another. The information of whether a password worked or not on a site means nothing to someone trying to hack your account.
Also 2FA sites do do this already. Google and Amazon both do this along with many others (and increasingly many). Also it does not have to force a password reset. A notification email about an attempt is sufficient, you can decide for yourself whether it was you or a suspicious attacker.
Personally I don't know enough to know if that's the case?
So all this discussion about how to handle the failed login is somewhat pointless.
I’m waiting for the release of the new macOS and I’m going to evaluate using the native implementation and ditching 1P.
[1] https://nuculabs.dev/2018/06/30/how-to-sign-git-commits-with...
Congratulations. This is the most persnickety HN comment I've read. And I've been here more than a decade.
You can tell i'm really reaching for bad things to say about it, haha
If MFA can be configured using myriad choices, should a user be prompted to "Insert security key" or "Input security code" or "Send code to your email/SMS" or "Tap YES on your mobile device"?
Since you can't know a priori what the second factor will look like, I'd say it's troublesome to try and present a challenge to every user regardless of their MFA configuration.
If your 2FA options all require the user to enter a code, you can simply display a "Please enter your 2FA code" dialog without divulging what kind of 2FA the user has.
An attacker brute-forcing the password could flood the user with multiple messages. The usual response is doing a password reset, but that wouldn't work in your system.
I wonder how systems that use magic links handle this.
The UI could then use these error codes to display the correct prompt, and then resend the request with the appropriate second factor.
Wasn't something like this how Uber got hacked recently? Spamming the target until they clicked "yes" on the 2FA prompt?
This allows you to see the text in the tab when you have several tabs open.
Ideally tabs should be indented so you can see which tab you linked the page from.
The best implementation is the Firefox extension Tree Style tab https://addons.mozilla.org/en-GB/firefox/addon/tree-style-ta...
But simpler vertical tabs are on Vivaldi, OmniWeb which had them since the mid 1990s but unfortunately has not kept up with allowing other extensions, Opera used to have them when it was not Chrome. Chrome had them at one stage but reading the issues on that the developers really showed a complete lack of understanding.
Although, iOS has tab groups now. I rarely use them because the menu is out of sight so I forget. But on macOS they’re convenient for when I’m researching a topic.