151–160 of 160 posts
Earlier quoted context omitted.
With the recent controversy about Amazon and Google snooping in on smart speaker recordings, people should probably avoid reading out their passwords to human listeners.
How would they determine that a particular string of words was a password as opposed to any other sentence?
Earlier quoted context omitted.
I hope a future version of U2F will support enrolling a not-physically-present token by public key.
Not practical. The public key is different for each enrollment, on purpose to deliver pseuonymity. If you enable U2F for Facebook, and then I borrow your Security Key and also use it to enable U2F for Facebook, although obviously that key will now work for either of us for signing into Facebook, Facebook don't learn that it's the same device. If Microsoft compares the data from GitHub to their own U2F data, they don'…
Earlier quoted context omitted.
How would they determine that a particular string of words was a password as opposed to any other sentence?
If it's not a coherent sentence, that would tend to be a hint. There are other explanations, admittedly.
Earlier quoted context omitted.
Does Netflix show your full card number to you if you're logged in or is there some other justification for this level of security on it?
You need to login because accounts have different quality tiers (standard vs high definition) and different max concurrent user counts. Hulu does this much better though. They display a hulu.com shortlink on the TV app that you type into your browser on a computer, login if you aren't already, and click a button to authorise the TV.
Earlier quoted context omitted.
1Password lets you use dictionary words separated by spaces when generating random passwords. This can be really helpful on iOS/tvOS devices -- just use speech-to-text to type them in (not to mention being easier to remember).
With the recent controversy about Amazon and Google snooping in on smart speaker recordings, people should probably avoid reading out their passwords to human listeners.
But is Apple’s speech-to-text feature (like on the iOS keyboard or in tvOS) recorded? If not, I’d venture to say I’m (currently) OK doing that with Apple services. They’ve prioritized security and privacy admirably.
Earlier quoted context omitted.
> sure its better than not having 2FA but only a little better. I'm becoming convinced this is a pervasive fallacy (perhaps not for all users in all cases, but for many). Having SMS as your 2FA potentially makes your phone, phone line, and everything linked to it an attack target. So you might lose a heck of a lot more than you would if they were all unlinked. It depends kind of on what your current security practice…
Someone who steals your phone needs to have "physical access" to you. A random pickpocket is most likely to steal your phone and they're not interested in your phone. Most hackers never have physical access to people. The intersection between the 2 sets - hackers and pickpockets - approaches zero.
That they may have friends who they accidentally do this for?
That they may not detect the fake ID some random person with your name and number shows them?
Etc etc. None of this requires getting your phone.
This kind of shit coming from Microsoft is fucking rich. Then why do I have to change my password constantly on outlook and get routed to at least two different types of password change servers, one with rules stupider than another? Especially when I'm trying to use a password manager with a strong, long, random password and they are preventing me from doing so with their shitty UX and their limitation on characters?…
Sounds like the place where you work has assigned some dumb password policies, and has a clumsy federation setup for password changes.
Earlier quoted context omitted.
Not practical. The public key is different for each enrollment, on purpose to deliver pseuonymity. If you enable U2F for Facebook, and then I borrow your Security Key and also use it to enable U2F for Facebook, although obviously that key will now work for either of us for signing into Facebook, Facebook don't learn that it's the same device. If Microsoft compares the data from GitHub to their own U2F data, they don'…
You can actually make it work and still maintain pseudonymity. A primary key could register a backup key by generating a site-specific keypair, encrypting the site private key using the backup base public key, and then using the encrypted site private key as the key handle. The primary key would need to know the backup key's base public key, but not it's base private key, and each site would still get a unique public…
The hardware today doesn't have a "base private key" (or public key) in the sense you mean. I feel like you're thinking about this like it's RSA, which it really isn't. RSA is weird because Encrypt and Sign are related operations, that is not how most things work. So you'd have to use key agreement plus symmetric crypto, and you'll struggle to fit everything into the current data structure sizes.
Earlier quoted context omitted.
Not practical. The public key is different for each enrollment, on purpose to deliver pseuonymity. If you enable U2F for Facebook, and then I borrow your Security Key and also use it to enable U2F for Facebook, although obviously that key will now work for either of us for signing into Facebook, Facebook don't learn that it's the same device. If Microsoft compares the data from GitHub to their own U2F data, they don'…
You can actually make it work and still maintain pseudonymity. A primary key could register a backup key by generating a site-specific keypair, encrypting the site private key using the backup base public key, and then using the encrypted site private key as the key handle. The primary key would need to know the backup key's base public key, but not it's base private key, and each site would still get a unique public…
Earlier quoted context omitted.
You can actually make it work and still maintain pseudonymity. A primary key could register a backup key by generating a site-specific keypair, encrypting the site private key using the backup base public key, and then using the encrypted site private key as the key handle. The primary key would need to know the backup key's base public key, but not it's base private key, and each site would still get a unique public…
Hmm. This would need a fairly substantial redesign in FIDO and might make the hardware more expensive, but in outline it sounds viable. The hardware today doesn't have a "base private key" (or public key) in the sense you mean. I feel like you're thinking about this like it's RSA, which it really isn't. RSA is weird because Encrypt and Sign are related operations, that is not how most things work. So you'd have to us…
You've correctly identified most of the tricky bits: the real algo involves key agreement plus symmetric crypto, it's a tight fit size-wise, and not all hardware has the necessary capabilities. However I think you're wrong about the conclusion. Can't say for sure though, as I didn't produce a working prototype. If you actually see this and want to discuss it in more detail you can find my email in my profile.