101–110 of 816 posts
Earlier quoted context omitted.
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.
Can you explain this more, I don't understand Google authenticator completely? Could a bad actor spoof a 2FA as they can with an email, and capture your input?
What's quite annoying is how agressive most products are into forcing this method over regular email+pw / Social Logins. Let me use my 100 chars password!
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…
- open website
- if not already logged in, log in to 1Password
- autofill password
- autofill TOTP
Now:
- open website
- if logged in to 1Password the Use Passkey usually shows up
- if not:
- log in to 1Password
- choose use passkey
- this almost always does nothing
- choose “use other method”
- choose “password”
- autofill that
- now there is another dialog to choose the 2fa method, choose Authenticator
- autofill that
Earlier quoted context omitted.
She follows same reset flow as before. Passkeys are identical in this respect to the passwords of yore.
Honest question: isn't that introducing some weaknesses, allowing the attacker to either reactivate password auth or add it's own passkey eh by tricking the user in accepting that change after receiving a mail with a link to accept that change? That would make the passkey unbreakable, but leave other easier to exploit weaknesses.
Earlier quoted context omitted.
Passkeys are in their infancy. You don't go about rolling out such patterns when most users haven't even switched yet and big players like Apple are still resisting attestations (last time I checked). The problem is that the feature is there and can be (ab)-used in this way, so it should be rejected on principle, irrespective of whether it's a problem right now . I understand the value of attestations in a corporate…
At the very least the spec should be painstakingly insistent on not requiring attestation unless implementors have really thought and understood the reasons why they need the security properties provided by attestation in their particular use case. And that it has to be something more meaningful than “be more secure this way” as security is not a rating (even though security ratings exist) but a set of properties, an…
https://github.com/keepassxreboot/keepassxc/issues/10407
> To be very honest here, you risk having KeePassXC blocked by relying parties
But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the spec authors who are doing their bidding anyway. It's a bit similar to sideloading apps, and it should probably be treated similarly (ie, make it a right for users).
Earlier quoted context omitted.
The article is not about MFA. It is about using email as a single factor.
Thats simple a lie or you didn't read the article. The very first bullet point states: Enter an email address or phone number That insinuates email OR SMS. It doesn't just mention email only.
Earlier quoted context omitted.
What do you mean by real backups? What's stopping you from backing up your keys? Its up to the passkey "provider" to allow passkeys backup/sync.
Not really, they have no incentive to provide such a thing nor is it mandatory for them to do so.
Earlier quoted context omitted.
Can you explain this more, I don't understand Google authenticator completely? Could a bad actor spoof a 2FA as they can with an email, and capture your input?
The attacker would just ask you for the TOTP code and forward that to Google.
I'd imagine a convincing enough modal would do the trick though, in a lot of cases.
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…
No, at least not on its own. Let's not repeat the mistakes.
Password managers are the way to go and ONLY FOR RARE EXCEPTIONS we should use dedicated MFA, such as for email-accounts and financial stuff. And the MFA should ask you to set up at least 3 factors and ask you to use 2 or more. And if it doesn't support more or less all factors like printed codes, OS-independent authenticator apps and hardware keys like yubikey, then it should not be used.
I'm having difficulty understanding what it means for an attacker to "send your email to a legitimate service"...
* Electronic mail (the technology)
* An email message
* An email address
* An email inbox
In this example they mean email address.