Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Yubikey Is the Digital Seatbelt We Need

zagaja.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: The Yubikey Is the Digital Seatbelt We Need

#61

Post by fph »

Terr_ wrote: post #55
fph wrote: post #9

Earlier quoted context omitted.

In the EU these hardware keyfobs are now forbidden for banking because they are considered less secure than app-based 2FA. The reason is that an app-based confirmation gives you the opportunity to review the transaction you are confirming; they can display "Are you sure you want to send 19.99 € to website.com with payment description 'subscription'?".

> In the EU these hardware keyfobs are now forbidden for banking [...] an app-based confirmation gives you the opportunity to review the transaction you are confirming; I'm confused, that seems like it confuses two independent aspects: 1. Whether the TOTP code comes from a fob-device versus a phone-device. 2. Whether some interactive interface you're using gives you a chance to see/confirm what you're about to author…

This assumes that the banking app receives push data about the transaction by the bank, and simply has an "approve" button A simple 2FA app like Authy/Aegis that produces a number has the same problems as the keyfob.

The threat model is: malicious actor posing as the bank website, but legitimate keyfob or legitimate app. With the keyfob, the website intercepts a valid password and a valid 2FA code; with the app, nothing happens because it doesn't receive push data from the true bank.

I hope it is more clear now!

Re: The Yubikey Is the Digital Seatbelt We Need

#62

Post by mzagaja »

coldblues wrote: post #30

Yubikeys are useless when someone can reset your password or 2FA using personally identifiable information that was just leaked. A lot of us who practice good security will be PWNED through large scale data leaks. Whenever I sign up, I sign up with fake information, and so should you. Most services will not KYC you, so just lie.

agreed, this only works if there are not "workarounds" or non-trivial ways to recover your account if you lose your yubikey.

Re: The Yubikey Is the Digital Seatbelt We Need

#63

Post by mzagaja »

Yizahi wrote: post #46

Bought yubikey on a sale a few years ago. Not usable for mobile in that model (4?) (but I knew it in advance of course). Then found out that most of the sites don't accept it in the Firefox, only in the Chrome and its clones. And so it is collecting dust somewhere in my old apartment.

I had similar issues with Safari a few years ago. The situation has vastly improved as most modern sites detect for FIDO2 support instead of just scanning your browser agent.

Re: The Yubikey Is the Digital Seatbelt We Need

#64

Post by mzagaja »

rcarmo wrote: post #15

Nope. It’s an add-on, but you can lose them. I am a bit flabbergasted that corporates are now handing them out like candy, but only one to a user. And if they lose them, they can’t even log in to request another.

Agreed, folks will need at least two.

Re: The Yubikey Is the Digital Seatbelt We Need

#65

Post by fph »

AndyMcConachie wrote: post #12
fph wrote: post #9

Earlier quoted context omitted.

In the EU these hardware keyfobs are now forbidden for banking because they are considered less secure than app-based 2FA. The reason is that an app-based confirmation gives you the opportunity to review the transaction you are confirming; they can display "Are you sure you want to send 19.99 € to website.com with payment description 'subscription'?".

This is false. I use a hardware thingy that I put my Dutch bank card into that generates numbers for logins and purchases. I have the option of using an app or the hardware card reader. I use a one time generating password hardware keyfob to login to the Dutch Belastingdienst. They require it and I don't think there is an app I can use for this purpose.

If it requires a smartcard I assume this is a different protocol, CAP. The introduction to this paper https://www.researchgate.net/publication/355241124_PSD2_Comp... (not mine) explains the system a little: the old hardware tokens in fig. 1 and 2 are those that cannot be used anymore; I assume you have something like the device in fig. 4?

Re: The Yubikey Is the Digital Seatbelt We Need

#66

Post by Terr_ »

fph wrote: post #61
Terr_ wrote: post #55

Earlier quoted context omitted.

> In the EU these hardware keyfobs are now forbidden for banking [...] an app-based confirmation gives you the opportunity to review the transaction you are confirming; I'm confused, that seems like it confuses two independent aspects: 1. Whether the TOTP code comes from a fob-device versus a phone-device. 2. Whether some interactive interface you're using gives you a chance to see/confirm what you're about to author…

This assumes that the banking app receives push data about the transaction by the bank, and simply has an "approve" button A simple 2FA app like Authy/Aegis that produces a number has the same problems as the keyfob. The threat model is: malicious actor posing as the bank website, but legitimate keyfob or legitimate app. With the keyfob, the website intercepts a valid password and a valid 2FA code; with the app, noth…

> with the app, nothing happens because it doesn't receive push data from the true bank.

I don't see how that feature matters to a man in the middle attack during logon, since:

1. User opens web browser at a phishing site, which is masquerading as their bank, and starts the login process.

2. Phishing site interacts with bank.

3. Bank sends push-notification to the phone# that's on-file for that user: "Hey, that you logging in right now? Press the Yes button if so."

4. User sees it, expects it, presses the button, and then proceeds to hand over their TOTP and password to the phishing site anyway.

I suppose it might help on a per-transaction basis if the phishing site tries to trigger a hidden transaction, but at that point the app is just a way to streamline: "We sent you a code by SMS, enter that code to confirm the transaction."

Re: The Yubikey Is the Digital Seatbelt We Need

#67

Post by OptionOfT »

donatj wrote: post #26
v1ne wrote: post #2

No, it's not. We need less shoddy practices to develop software, e.g. mandatory 4-eyes process for security-critical changes, thread modelling, and maybe more Hardware Security Modules that encrypt critical information. And if you need a second factor, I'm sure any smartphone-based TOTP will do. People already guard their smartphone well. No extra key fob needed.

You can get as many eyes as you want on all changes. I don't think it will help much. This sort of thing usually happens because of a change in something completely benign, rather than "security-critical changes". We recently had a pretty major vulnerability exposed by a PEN test (thankfully) that was caused by a single misplaced NOT ! operator in a pretty simple function, maybe 20loc with 100% test coverage as count…

Would branch coverage have helped you here?

And I think one of the approaches that helped me to write safer code is to parse, and not validate.

That way drastically limit the situations we can get into where we forget to validate certain conditions.

e.g. you have a User struct, and you want to do an action which requires you to validate whether the user is an admin.

2 options here

* validate whether the user is an admin (which could happen multiple times when you're invoking distinct functions as part of a workflow)

* parse the User into an AdminUser. If the user is an admin, the function will work, and then you can pass on your new struct into places that require an admin. If it fails, the user is not an admin. Now you have merged all your checks into 1 place.

Re: The Yubikey Is the Digital Seatbelt We Need

#68

Post by rightbyte »

fph wrote: post #9
rightbyte wrote: post #6

Earlier quoted context omitted.

The banks used to hand out key response generation devices for that. No interface at all but the buttons. There even was a paper version where you scratched to get the key. Like, it was way better.

In the EU these hardware keyfobs are now forbidden for banking because they are considered less secure than app-based 2FA. The reason is that an app-based confirmation gives you the opportunity to review the transaction you are confirming; they can display "Are you sure you want to send 19.99 € to website.com with payment description 'subscription'?".

You could have a keyfob to identify and app to confirm.

Re: The Yubikey Is the Digital Seatbelt We Need

#70

Post by donatj »

OptionOfT wrote: post #67
donatj wrote: post #26

Earlier quoted context omitted.

You can get as many eyes as you want on all changes. I don't think it will help much. This sort of thing usually happens because of a change in something completely benign, rather than "security-critical changes". We recently had a pretty major vulnerability exposed by a PEN test (thankfully) that was caused by a single misplaced NOT ! operator in a pretty simple function, maybe 20loc with 100% test coverage as count…

Would branch coverage have helped you here? And I think one of the approaches that helped me to write safer code is to parse, and not validate. That way drastically limit the situations we can get into where we forget to validate certain conditions. e.g. you have a User struct, and you want to do an action which requires you to validate whether the user is an admin. 2 options here * validate whether the user is an ad…

Yeah, almost certainly. We had looked into enabling branch detection several years ago, but it had slowed our suite down to the point where we were not sure it was worth it. Maybe worth looking into again.

I do generally like that technique of returning more vetted objects, but I'm not sure that it scales. Our users have close to one hundred different permissions based on the features their admin pays for, having an object for every type seems like a lot. Every combination of types is straight out.

The original issue I was talking about I don't think could have been helped. It was an encoding problem that could have potentially lead to XSS injection with a very specific set of GET parameters. I was frankly surprised that the PEN testers managed to find it.

Post reply on HN