The attack pattern is: 1) User goes to BAD website and signs up. 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.” 3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email. 4) GOOD sends a one-time login code email to the user’s email address. 5) The user is very likely to trust…
If we are talking about real time phishing then sending a code to the email is as secure as a 2FA authentication with password and Google Authenticator code.
Emailing a one-time code is worse than passwords
461–470 of 816 posts
Re: Emailing a one-time code is worse than passwords
#462Earlier quoted context omitted.
uh no - a password manager is an open source application you can compile and install yourself if you want. Its nothing more than a small specialised database with a excel like interface. Personally I think that the argument that things are "too complicated for the average user" eventually gets gets you users that find breathing and sphincter function too complicated.
I’ve been observing this space for two decades and haven’t come across a single open-source password manager that actually works, is properly maintained, has an acceptable security track record, and comes with a similarly well-maintained browser extension that protects both my clipboard and myself from phishing.
/me wonders if this is a "recommend me a nice open source, offline password manager" question in disguise.
Re: Emailing a one-time code is worse than passwords
#463Earlier quoted context omitted.
They only read what they need to finish what they are currently trying to do, which in this case is the code they need to log in.
I know from experience that well designed messages with secure code are very understandable and make it virtually impossible to miss the warning. On what grounds you say people dont read? Any evidence?
This premise seems flawed.
How can you possibly know from experience that something is “very understandable” if the only brain you have is your own?
How do you anticipate how other people with brains different from yours are going to behave in situations of cognitive impairment or extreme stress, things that happen in the real world?
Re: Emailing a one-time code is worse than passwords
#464Re: Emailing a one-time code is worse than passwords
#465Earlier quoted context omitted.
Passwords are (or, rather, SHOULD be) cryptographically hashed rather than encrypted. It's possible to compute a hash over data which is longer than the hash input block size by feeding precious hashes and the next input block back in to progressively build up a hash of the entire data.
Yes, in this case it would be easier to brute-force the key instead of the password, so the additional characters don't really help.
Re: Emailing a one-time code is worse than passwords
#466The attack pattern is: 1) User goes to BAD website and signs up. 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.” 3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email. 4) GOOD sends a one-time login code email to the user’s email address. 5) The user is very likely to trust…
>"I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money." More like abuelita gets robbed at gunpoint and made to unlock and clear out her bank account, then has no recourse at home because her device was taken. I live in a third world country and even 2FA simply isn't viable for me due to how frequent phone robberies are. I've had to do the pro…
Re: Emailing a one-time code is worse than passwords
#467Earlier quoted context omitted.
> I'd rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money. The problem is that I can physically show up at my local bank branch or at my job's IT helpdesk to get my account back, but I can't show up at the Googleplex or at Facebook's or Xitter's HQ and do the same. Device bound passkeys are very error prone for the latter scenario, since users wi…
To add, services account for that failure by introducing something worse: a customer service backdoor where you can get into an account with very weak or nonexistent authentication. With Amazon's live chat, someone was able to get into my account by providing an address in the same city as the destination of my latest Amazon order. You see this with 2FA since "sorry lol you've lost your account forever" isn't an opti…
Re: Emailing a one-time code is worse than passwords
#468The attack pattern is: 1) User goes to BAD website and signs up. 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.” 3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email. 4) GOOD sends a one-time login code email to the user’s email address. 5) The user is very likely to trust…
The problems of Passkeys are more nuanced than just losing access when a device is lost (which actually doesn't need to happen depending on your setup). The biggest problem are attestations, which let services block users who use tools that give them more freedom. Passkeys, or more generally challenge-response protocols, could easily have been an amazing replacement for passwords and a win-win for everyone. Unfortuna…
but I don't think attestation per-se is bad, if you are a employee from a company and they provide you the hardware and have special certification requirements for the hardware then attestation is totally fine
at the same time normal "private" users should never exposed to it, and for most situations where companies do expose users to it (directly or indirectly) it's often not much better then snake oil if you apply a proper thread analysis (like allowing banking apps to claim a single app can provide both the login and second factor required by law for financial transactions, except if you do a thread analysis you notice the main thread of the app is a malicious privilege escalation, which tend to bypass the integrity checks anyway)
But a lot of the design around attestation look to me like someone nudged it into a direction where "a nice enterprise features" turns into a "system to suppress and hinder new competition". It also IMHO should never have been in the category of "supported by passkey" but idk. "supported by enterprise passkey only" instead.
Through lets also be realistic the degree to which you can use IT standards to push consumer protection is limited, especially given that standard are made by companies which foremost act in their financial interest, hence why a working consumer protection legislation and enforcement is so important.
But anyway it's not just the specific way attestation is done, it's also that their general design have dynamics push to a consolidation on a view providers, and it's design also has elements which strongly push for "social login"/"SSO" instead of a login per service/app/etc. i.e. also pushes for consolidation on the side of login.
And if you look at some of the largest contributors you find
- those which benefit a ton from a consolidation of login into a few SSO providers
- those which benefit from a different from a login consolidation (consolidation of password managers) and have made questionably blog entries to e.g. push people to not just store password but also 2FA in the same password manager even through that does remove on of the major benefits of 2FA (making the password manager not a single point of failure)
- those which benefit a ton if it's harder for new hardware security key companies, especially such wich have an alternative approach to doing HSKs
and somehow we ended up with a standard which "happened" to provide exactly that
eh, now I sound like a conspiracy theorist, I probably should clarify that I don't think there had to be some nefarious influence, just this different companies having their own use case and over fitting the design on their use case would also happen to archive the same and is viable to have happened by accident
Re: Emailing a one-time code is worse than passwords
#469Earlier quoted context omitted.
>"I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money." More like abuelita gets robbed at gunpoint and made to unlock and clear out her bank account, then has no recourse at home because her device was taken. I live in a third world country and even 2FA simply isn't viable for me due to how frequent phone robberies are. I've had to do the pro…
> More like abuelita gets robbed at gunpoint and made to unlock and clear out her bank account, then has no recourse at home because her device was taken. You are describing the current status quo, without passkeys. This is already possible. Well, except maybe for the "without recourse" part, because there are some legal and policy avenues available for dealing with this situation.
Re: Emailing a one-time code is worse than passwords
#470Earlier quoted context omitted.
Well, having your passkey provider blocked for doing that might stop you. https://github.com/keepassxreboot/keepassxc/issues/10407 Of course, they might just block you for not being on a whitelist of approved providers anyway.
That's such a strawman argument. Read the link you pasted again
> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
> The reason we're having a conversation about providers being blocked is because the FIDO Alliance is considering extending attestation to cover roaming keys.
> From this conversation it sounds like the FIDO Alliance is leaning towards making it possible for services to block roaming keys from specific providers.