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.
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.
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).
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.
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.
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=
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.)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
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 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.
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.
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.
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.