Usually I polish my work a bit more before releasing it publicly, but I really wanted to give people interested in making fediverse apps for everyone a bit of a head start.
Here's a very work-in-progress authentication server I use for my fediverse connections data visualization project:
have #privacy about health info (think genetic disorders)
be anonymous in terms of DNA-person match (which means ethically working researchers can not include their data in studies, e.g. GWAS etc.)
Sensitive data matters. Biodata is one of the most sensitive types of data you can think of. My advice: Don't use it as a first auth factor. And definitely not as a sole key for crypto.
My PhD thesis on the usability, security, and privacy of Risk-Based Authentication (RBA) is now published. For free, for everyone, as I believe that publicly funded research should be open to the public.
On 239 pages, you will learn how to strengthen password-based authentication with RBA while being privacy-enhanced and accepted by users.
“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.”
PassKeys seem like a bad idea. Google backs them up to the cloud, so if your Google account is compromised then all your private keys are compromised. I don't see how that's an improvement over password+2FA at all.
Now security keys I get; keep the private key on an airgapped device. That's good. Hell I even keep my 2FA-OTP salts on a YubiKey.
Some of the WCAG 2.2 guidelines around authentication are interesting when it comes to user experience for logging in, reinforcing the need to allow users to copy and paste passwords and use their password manager extension, among other things.
You can check Accessible Authentication (Minimum) (Level AA) for more details: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html#examples
I wonder if there will be conflicts with security teams, though, what do you think? #Authentication#Accessibility
> A new #login technique is becoming available in 2023: the #passkey. The passkey promises to solve #phishing and prevent password reuse. But lots of smart and security-oriented folks are confused about what exactly a passkey is.
Jean-Luc di Manno, digital #payment and #authentication solution architect at Fime, and member of the W3C Web Payments #WorkingGroup, presents how Secure Payment Confirmation (SPC) addresses a key issue in the #European payment ecosystem.
Question about implementation of #Passkeys. As I understand it, having a user login with passkey but without UV (User Verification) is not necessarily MFA as it could just be a stolen security key (Something you have).
How is (or should) #MFA with Passkeys implemented in practice? By setting UV as "required"? Or by setting UV as "preferred" and then based on the user response prompt for another factor (eg. #TOTP) in case there was no UV? I am a bit confused about how to fit Passkeys into the current #authentication logic.
Fraser will cover how distributed #authentication has evolved, and the place of technologies like #FIDO2#passkeys and external #OAuth2 providers in the new landscape.
Worried about account takeover? You're not alone! Attackers often misuse the "forgot password" mechanism to hack us.
Our latest study revealed a game-changer to counter this: Risk-Based Account Recovery! Platforms like Google now tailor recovery mechanisms based on your device and location context, making it hard for bad actors but easy for legitimate users.
> Digital Identities aren’t something unique to the fediverse and it’s not something Mastodon could stop if they wanted to. Nomadic identity is coming to the internet. The only question is who is going to own your identity. VISA/Mastercard, your government, Google, Microsoft, or you.
For user accounts that have enabled multifactor authentication, how do you handle self-service password resets? On online platforms, it is usually possible to reset the password via email. I think that is fine for accounts that don't use multifactor authentication. But what if a user logs in with their phone number (They have no email, just the phone) and use text message as their second factor? Sending a password reset code via text message would be a bit stupid. This would mean that the user doesn't really have two-factor authentication if you can reset the first-factor with the second-factor.
I do currently not allow self-service password resets if a user has multifactor enabled. They are required to get in contact with customer support in that case. For our use-case this is ok, but it's obviously not very user-friendly. However, I don't really see a solution in the case where the phone number is the primary identifier and second-factor. I am interested in some thoughts on the topic.
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”: