Hacker News Reader

Comment by zamalek | Hacker News Reader

> This seems very feasible in the context of a government agency, because each employee can receive her token as part of her onboarding when she is hired. However, this sort of thing is harder to do if you are a SaaS service

It's not. Allow SMS to be disabled in favor of a more secure option (WebAuthn). Strongly suggest that users purchase a token.

View on HN

I find tokens to be incredibly hard to manage and if you lose them you’re completely screwed forever. And then there’s the problem where every employee gives you a security key do you don’t know which one has which credentials (yes you can add keys but managing all of that physical stuff has a cost).

Although they’re not popular in security circled because technically they’re still vulnerable to phishing websites, I prefer TOTP apps like Google authenticator because it’s backed up to the cloud so even if I lose my phone I know I can get back the keys; it’s the best trade off for security vs usability.

I was confused on my first read through: this guidance seems to refer to federal enterprise applications, not necessarily customer-facing services.

It seems reasonable to me to require employees to use a physical authenticator. Heck, how many of the people here use them and require employees to use them? Often to secure access to applications and resources less consequential than Official Acts Of The Federal Government.

It would feel less reasonable (and a throwback to the ‘00s) to mail out hardware authenticators to customers/members of the public just to, say, buy stamps from the USPS or something.

But the employee needs to be responsible enough not to lose it, they definitely need to not be able to back it up to god-knows-what consumer-grade provider (or to duplicate it at all). And when they lose it, IT needs to know to invalidate the lost one and issue them a new one.

My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken?

>needs to be responsible enough not to lose it.... needs to know to invalidate the lost one and issue them a new one.

Ah, the never-ending circle of life.

> My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken?

I'm a Federal contractor. At least for my agency this is table stakes for any application period. I don't even have a password anymore. For the very small number of legacy applications that don't support smart card auth I have to log in to a different service to get a temporary password that expires after 24 hours.

The main issue with TOTP is that it's still vulnerable to phishing, though it certainly is significantly better than SMS.

Yes but as I said, I’m personally less concerned about a successful phishing attack. I can see why you might be concerned as an employee to a multi billion dollar business but attacks on my personal safe are unlikely to be sophisticated enough to fool me / I’m not a target for sophisticated ones. UX vs threat model tradeoff.

You should be very concerned about phishing. The push towards modern phishing-resistant authentication was spurred from large scale studies of phishing success against very smart targets (security teams at Google, for instance). It's probably drastically less expensive to put a "sophisticated" phishing attack together than it is to target you with a memory corruption exploit.

Phishing is the major vector for compromise.

There is nobody that is unphishable. Very competent, careful, highly-skilled employees can be and have been phished.

Passkeys might provide a decent middle ground here, assuming current UX issues can be improved upon.

Apple effectively fixed the UX issues, so we’re just waiting for the future to be evenly distributed.

I would certainly hope not, depending on the implementation it would be placing critical keys in the hands of an unknown/untrustworthy third party. The alternative is to manage the key infrastructure as a company which brings its own overheads, so the most obvious implementation goes back to WebAuthn.

Reply on news.ycombinator.com