671–680 of 816 posts
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…
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…
edit: kam corrected me below.
Consider this scenarioUser initiates login on your site.
1. You generate a code_verifier (random) and a code_challenge = SHA256(code_verifier) and store the code_verifier in the browser session (e.g., local/session storage, secure cookie, etc.).
2. You send the code_challenge to the server along with the email address.
3. Server sends the email with a login code to the user, recording the challenge (associated with the email).
4. User receives the email and enters the code on the same device/session.
Client sends the code + code_verifier to the server. Server verifies: Code is correct. SHA256(code_verifier) == stored code_challenge.
The end result is that The code cannot be used from another device or browser unless that device/browser initiated the flow and has the code_verifier.
A combination of the above and a login link might help. But ultimately, the attacker will be relying on the gullibility of the user. The user will have to not check the urls
Assuming the bot knows to send a code_challenge and send the code_verifier together with the verification code
But then again, GOOD can just also ensure that their otp can only be completed from the GOOD domain/origin. That would shore things up at least.
Earlier quoted context omitted.
For a long time 2fa apps (other than Bitwarden and maybe some others) would lock you into the app and not let you export it. Websites don’t usually expose the text version of the code, just the QR.
QR has trivial format and code is easily extractable.
Earlier quoted context omitted.
Hi, since you mentioned me, that's not what was said and putting it in quotes as if I did is really inappropriate. I'll post the same response I replied to other on a different thread: Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues). 1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the cre…
They paraphrased what you said in the thread, but I don't think it's much of a misrepresentation. You may have "been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice", but as soon as one such credential manager allows export that becomes "something that I have previously rallied against but rethinking as of late because of these si…
> The fact that that possibility exists,
The possibility does not exist in the consumer synced passkey ecosystem. The post is from a year and a half ago.
Earlier quoted context omitted.
What makes you think that the Webauthn standards are "targeted at running services for the general public"? > It seems like the requirements already diverged. No, the requirements are _contextual_. This isn't a new idea.
The fact that sites targeted at the general public are prompting me to use them. Should websites avoid using passkeys and webauthn? Would you like to tell them that they're doing it wrong?
What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?
Earlier quoted context omitted.
Bcrypt alone is unfit for purpose. Argon2 does not need its input to be predigested. It's easy for somebody who knows this to fix bcrypt, but silently truncating the input was an unforced error. The fact that it looks like and was often sold as the right tool for the job but isn't has led to real-world vulnerabilities. It's a classic example of crypto people not anticipating how things actually get used. (Otherwise,…
Peppering is for protecting self-contained password hashes in case they leak. It's a secondary salt meant to be situated 1) external to the hash, and 2) external to the storage component the hashes reside in (i.e. not in the database you store accounts and hashes in). The method has nothing to do with trying to fix anything with bcrypt. You should be peppering your input even if you use Argon2.
You do not have to do any transformations on the input when using Argon2, while you must transform the input before using bcrypt. This was, again, an unnecessary and dangerous (careless) design choice.
Earlier quoted context omitted.
The fact that sites targeted at the general public are prompting me to use them. Should websites avoid using passkeys and webauthn? Would you like to tell them that they're doing it wrong?
I missed a word out from my question. Let me try again. What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?
I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec.
Passwords suck. It's depressing that otherwise good alternatives carry poisonous baggage.
If you make something possible, it will be used.
Earlier quoted context omitted.
To defend Redmond here, Entra is an enterprise system. If the company you work for or are interfacing with wants to enforce attestation, that's their business. B2C I would expect more latitude on requiring attestation.
Exactly. For personal authentication, you are at least personally incentivized to do the right things. For corporate auth, people will do whatever it takes to skip any kind of login. I once knew a guy who refused to let his office computer go to sleep just to avoid having to enter his password to unlock his computer. He was a really senior guy too, so IT bent to allow him do this. What finally made him lock his compu…