We really need to do away with this type of authentication.
The tests are often ambiguous. More importantly, they don’t meet accessibility requirements noted in WCAG 2.2. Specifically section 3.3.8 on “cognitive function tests”:
“Microsoft’s Offensive Research and Security Engineering (MORSE) asked us to evaluate the security of the top three #fingerprint sensors embedded in laptops and used for #Windows Hello fingerprint #authentication. Our #research revealed multiple #vulnerabilities that our team successfully exploited, allowing us to completely bypass Windows Hello authentication on all three laptops.”
#2FA: I’m using the Google Authenticator app but I’d like to replace it. Which 2FA app should I give a try instead? I’d much prefer something open source.
When implementing #WebAuthn on an Identity Provider's side. Where exactly should one draw the line between #SecurityKey and #Passkey? I see that most platforms make a distinction between those. Can anyone link me some article or blog post on this topic? If I were to implement security key and passkey support on a provider that does not yet support any WebAuthn, should I go down the same route?
My current assumption is that during passkey registration you'd set "residentKey = required" and "userVerification = required", whereas for a security key you'd set "residentKey = discouraged" and "userVerification = preferred".
Also, I'm assuming that a security key can also function as a form of #passwordless multi-factor authentication if UV was true during registration AND authentication. Obviously without the neat part of Passkeys where you don't have to manually enter the username.
Challenge based MFA applications are more secure than the push notification based MFA.
A careless admin might tap on the Approve button easily on push notification based MFA, whereas challenge requires the user to know the number to be submitted. Since s/he doesn't know it (because someone else triggerrd the MFA), challenge-response can't be completed and the account will not be able to accessed.
The #compromise of the fingerprint sensor implementations used for #WindowsHello#authentication is hardly surprising. Biometrics is very hard to get right, and even then there is the fundamental issue: Biometrics alone shouldn't really be used for authentication to begin with.
Even if the current flaws would be fixed, I would not recommend using biometrics alone for authentication. It could be used as part of multi-factor authentication, assuming the other factors are strong enough.
Are there any connections between the Mastodon development crew and these apps? If companies and news orgs or individuals are using these apps, and they don’t support Mastodon, how can we expect them to move to Mastodon? #Twitter#Mastodon#TwitterMigration#SocialMedia#apps#SMM
Mastodon is only one platform which uses (a subset of) #ActivityPub. All platforms which use any parts of ActivityPub constitute the #Fediverse. And they can all interconnect with all the other servers/platforms.
These apps appear uninterested in supporting ActivityPub platforms. The platforms have public #API, mature #authentication systems, mostly-good docs. Perhaps they do not see a route to capitalisation.
I see Google is beginning their next phase in Passkeys rollout by offering to default Google accounts to on-device passkeys instead of passwords.
Now, this is a good development in the very high level. Passwords do need to die.
But before you accept that offer, consider that Google Authenticator very recently led to a major compromise, because Google failed to inform (sophisticated) users about how they back it up.
I've rooted for so many methods to finally retire the password from our toolbox of authentication methods, I can't even remember what got me started. So I hold a lot of hope that Passkeys are finally the thing that will stick. But security is messy, and everything comes with downsides. What are some of the the downsides of the passkey? A review. https://osma.medium.com/the-trouble-with-passkeys-64c791ef5620 #passkeys#authentication#infosec
SMTP Smuggling Allows Spoofed Emails to Bypass Authentication Protocols (www.securityweek.com)
A new attack technique named SMTP Smuggling can allow malicious actors to send out spoofed emails that bypass authentication mechanisms.