Hacker News new | past | comments | ask | show | jobs | submit login

> you need to start banging on pots and pans up your reporting chain to get your security team

Not sure how Webauthn works, but as long as it can be stored in the cloud, I'm fine.

Industry is going towards this scheme of physical 2FAs that assume some living conditions appropriate for whoever designs things, without alternatives for people who don't fit that ideal way of doing things. Physical stuff gets lost or stolen. I'm optimizing for when I am traveling from home around the other side of the world, 6 time zones away, and my phone / stuff gets lost.

2FA is already unmanageable at this point: "just use your recovery keys" is what people tell you, but that's NOT a viable solution to the problem. Sorry but my recovery codes are in a safe lock, 10,000 Km away from me, I just lost the purse with my phone, or my device broke, or got stolen, or whatever, and need the damn TOTP code to telework _right now_.




Your bus factor is the problem here, not your 2FA system.

"I absolutely need full access to systems while working on a random device using only my password" means that phishing gives all the keys to the kingdom and that you don't have systems in place to make sure things work when people go on vacation.


> ...or whatever, and need the damn TOTP code to telework _right now_.

Do you? Really?

"Your lack of planning is not my emergency"

Unless you're the founder+owner, I'd expect that tech support at your company wouldn't expedite your access request just because you feel entitled to it.

Will a million dollar sales call fail and/or have to be rescheduled because you didn't have 2FA access? You should accept the responsibility, apologise with whoever it is that you let down and move on.

Of course, companies should give us all the tools we need to succeed. Not cheap out on their budget and then shift the blame on us. This means also giving you multiple devices and tokens, to ensure that you have redundancy (if a device fails you have a backup, if you lose a token you have a backup).

Even then, it can happen that right after a trip you might've realized that you left home and/or misplaced your security token. The professional thing to do is to communicate it to the company right away (so they can arrange to verify your identity and/or to ship something to you) once you discover it when you land. Not ignore the problem until you'd be back at work and in urgent need to attend some work meeting.

Travelling across the world, 6 time zones away is not something that you can do with every job. If your company allows it, that's a perk, but you should also treat it with the due care that requires.

Missing a day of work is small stuff compared to the risk that the whole company runs by allowing their employees auth to be phished. If you have to skip a day (or more!) of work on extremely short notice, it might be an unpleasant conversation with your manager, but it's a conversation that you should have nonetheless. (btw, do you have the phone number of your manager on your personal phone? if you lose your work devices, it's important to still have a way to reach out to them).

Security tokens are cheap, just make sure that you have N+1 (one for each device you need, plus one)


> Will a million dollar sales call fail and/or have to be rescheduled because you didn't have 2FA access? You should accept the responsibility, apologise with whoever it is that you let down and move on.

Spoken as someone who has clearly never had any tech duties in the financial sector.

You don't understand what time critical means until a dealer's access stops working / computer freezes 10 minutes before market close. ;-)

That could easily cost millions. That could easily loose the company the entire account.

And god help you if the market moves overnight and you were unable to get the trade on ...

A grovelling apology to the client might help avoid a complaint to the regulator, but you're unlikely to keep their business.

So yes, there will always be genuine need for IT to be able to bypass a user's 2FA, because its certain that user won't be able to wait until you send them a new Yubikey in the post.

And yes, financial companies are also well aware of phishing / SE and take appropriate steps to ID user.


The answer there, clearly, is to not have an individual be a potential SPOF. If failure of that kind of support costs millions of dollars, you absolutely need to have the ‘walked in front of a bus’ scenarios worked out.


> The answer there, clearly, is to not have an individual be a potential SPOF. If failure of that kind of support costs millions of dollars, you absolutely need to have the ‘walked in front of a bus’ scenarios worked out.

I'm not going to post details in public, but suffice to say, you are over-simplistic and don't understand the context.

Sticking with my example of dealers, let's just say people like dealers are not employed in great numbers in all but the largest financial organisation. Let's also say that there are certain events and certain times of day when the entire dealing desk is, shall we say, "busy and stressed out". There is little scope for a colleague to step in at those times, because everyone is franticly busy on the phones with their own workload.

In terms of 2FA therefore, the "walked infront of a bus" scenario is to (after correct security protocol, which includes, but not limited to, senior board-level management and compliance being told and approving) temporarily bypass 2FA for that dealer. Telling the dealer to pass his work to a colleague is just not going to work.

Of course financial organisations have "walked infront of a bus" plans. But they equally have levels of escalation of plans. Sometimes doing stuff at lower level with the help of the IT department is more than sufficient.

I'm not going to elaborate further.


> Sticking with my example of dealers, let's just say people like dealers are not employed in great numbers in all but the largest financial organisation. Let's also say that there are certain events and certain times of day when the entire dealing desk is, shall we say, "busy and stressed out". There is little scope for a colleague to step in at those times, because everyone is franticly busy on the phones with their own workload.

That just sounds like optimizing for efficiency over redundancy, which is a trade off you can make, but not one that is required. Financial organizations could hire more dealers so you don’t have “little scope” for others to help out. Or they could staff an IT group that is open 24/7 ready to help these traders instantly.


The options you are considering seem to be putting over bypassing MFA is:

- hire more dealers ($$$$$$$$$) - staff an IT group that is open 24/7 ($$$$$$$$$) - bypassing MFA ($)

Not sure if you are being serious that the other options are comparable to the 3rd for a business


That’s what I mean by optimizing for efficiency. They’d rather not spend the money to operate in a way that allows for them to be secure or redundant.

Honestly if they are going to just skip MFA everytime it’s a bother they might as well just not use it


I see what you mean, appreciate the clarification


Unfortunately, some places' idea of having this problem "worked out" is to react by making the SPOF's life miserable with punishment or firing. And the bus scenario is "covered" by having the scapegoat be dead. Not a good strategy for the business, of course, but it's definitely the reality at some places. Actually having the SPOF scenarios prevented would be a much more mature approach.


this does not even apply to Uber in any way.

There is no job at uber that could not be done by a coklwague that has access. There is no situation where 10 million delay in uber loses you 100 million dollars


> "Your lack of planning is not my emergency"

> Unless you're the founder+owner, I'd expect that tech support at your company wouldn't expedite your access request just because you feel entitled to it.

You think corporate IT support doesn't help out users who've forgotten their credentials?

I can assure you, resetting forgotten passwords is probably one of the most frequent things first-tier IT support does. And sorting it out synchronously while they're on the phone is normal - it's not like you can do it asynchronously when they're locked out of all the async messaging systems.

(Of course, the bypass might take an inconvenient form - like calling you back on the phone number HR have on file with you, or a three-way video call where your boss vouches for you)


I'm sure it can be frustrating, the idea of employees who don't seem to be sufficiently diligent, and then expect IT to drop everything to fix problems that the employee caused.

Ideally, the IT department is empowered to work proactively on effective infosec, for all of the company's real-world situations.

Then the standard for responsibility of each non-IT employee is only good faith compliance with what IT dept. told them -- not to be an IT expert who can reason about infosec tactics and strategy.


I think the tradeoff between "the entire company is breached" vs "I lost my device while on vacation and I have a tight deadline" is probably best geared to help prevent the former than the latter.

(Webauthn by design requires physical hardware tokens, not cloud storage.)


WebAuthn does not mandate any kind of form factor[1], external tokens use CTAP for USB/Bluetooth/NFC, Apple FaceID/TouchID and Windows Hello using proprietary interfaces with the built-in hardware. Blink-based browsers ships with a virtual authenticator for debugging[2] and there are a few more[3].

Apple and Google already announced cloud syncing earlier this year, using "passkey" as a friendlier term for end-users. QR codes already allow for cross-ecosystem non-synced use cases, like using my personal Android phone to log in an account with my work Macbook. https://securitycryptographywhatever.buzzsprout.com/1822302/... is a good listen to catch up on the latest developments.

[1]: https://www.w3.org/TR/webauthn-2/#authenticator-model [2]: https://developer.chrome.com/docs/devtools/webauthn/ [3]: https://github.com/herrjemand/awesome-webauthn#software-auth...


You are correct, and I should have said "Webauthn is designed to rely on something you have" rather than saying "physical tokens," since the latter is confusing and could be taken to imply a form factor.

If you lose the things you have while on vacation, though, it will be inconvenient (which is what the OP seemed to be against, and what I meant to be responding to). I think for a corporate environment that inconvenience is a reasonable tradeoff.


> (Webauthn by design requires physical hardware tokens, not cloud storage.)

That's not true. As an obvious reductio ad absurdum, you could just build a fake USB driver that presents as a security key. But more practically, I'm pretty sure that iOS the Webauthn secrets are synced cross-device via iCloud.


Not true. Apple Passkeys is cloud based; syncs through iCloud and is webauthn.

Nothing about the spec mandates physical hardware tokens. Software tokens work fine too. https://developer.apple.com/passkeys/


To start with, let's say you have your corp laptop and corp phone (both are access devices and both should have device bound certificates), and your yubikey for webauthn, and your corp photo-badge and your government issued photo identity (all three are authentication factors).

Let's say you are traveling and you lost one or both of your access devices. First immediate step is contact your security hotline and notify them that you lost the device(s). They should immediately remote-wipe/disable said devices.

If you are visiting another branch office of your company, local IT should be able to physically verify you with your government issued ID and your corp badge and issue you a temporary laptop/phone and get you basic access privileges.

If you need high-trust access, it should require more verification steps (your manager has to confirm you are not on vacation and that it is really you who is meeting with the IT shop etc), and more elapsed time (this sucks but it is important to slow things down anytime primary access devices are reissued due to loss/theft).

Obviously, if you are a super critical person and have become a single point of failure, that's bad.


> I just lost the purse with my phone, or my device broke, or got stolen, or whatever, and need the damn TOTP code to telework _right now_.

So, wait for a new authenticator device to be shipped to you. Like, if the work laptop broke, you'd presumably have to wait on a replacement for that, too...


The way I view these types of objections - I know one or two people who have lost their wallet more than a couple times in their live ("I need new ID!") and the rest of the people I have know have NEVER lost their wallet. Even people who have their wallet stolen often recover it later (thieves remove valuable part and throw it away so they aren't caught with it). We probably shouldn't design our security procedures around the very, very small number of people who have lost their wallet a few times as an adult.


"User lost their token/forgot their password/lost access to their e-mail/lost their phone/changed their phone number/changed their mailing address" may only be 0.1% of users - but it's 100% of social engineering attacks :)


Yep, and the GP is saying that you should optimize your procedures to deal with the attacks, not with the honest errors. Exactly because the honest errors almost never happen (even when there are thousands of people on the organization).

Anyway, if a complaint about procedures makes exactly as much sense if you replace the cause with "gets sick and spend a day at the hospital" without losing meaning, then it's not a valid complaint.


I'm curious what problems physical tokens have that don't have easy workarounds. I have a Yubikey on my keychain with home/vehicle keys that supports USB and NFC (so it works with my phone).

For work, I use that as a backup. For personal use, I just leave a cheap Feitian plugged into my desktop. For work, I just leave a slim USB-C plugged into my laptop all the time (if the laptop gets stolen, they still need the first/password factor)

In addition, emergency recovery codes just get copied to a note in my password manager. You don't need to lock recovery codes in a safe--they're only 1 of the two factors. You just need to make sure you don't store them in the same place as the other factor (or, if you do, that place is protected with multiple factors)


Just plug your recovery key in a backup server on a network you have physical access to and expose ssh port as a tor hidden service (optionally with onion client auth if you're paranoid)? Either way as long as you have backup keys that don't involve biometrics you can set up your own infra for that as you see fit.

But yeah, the face whatevers really must not be the only option.


I just travelled eight time zones away and (apparently) lost my security key there. It caused pretty much zero issues, I just stopped by the office and picked up a new one to bootstrap off a spare key. Then I revoked the old one. If you don't have another key (you should really get one!) you can call in and they'll figure it out.


How did you drop into the office to get a new key? Is your office eight time zones away from where you live?


Nope, I was traveling on business to a place with another office. This is true of a significant portion of business travel, no?


Perhaps, but what does this have to do with the situation you are responding to where the person WASN'T doing that.

I have literally never travelled to "another office" in my entire career. But then I've always worked for startups ...


> Not sure how Webauthn works, but as long as it can be stored in the cloud, I'm fine.

Apple is solving for this exact request with Apple Passkeys; it is just WebAuthn under the hood with cloud backup, multi-device, and sharing built in.


Truly secure access to computers is simply not possible under those conditions. A hardware root of trust used to verify your identity is mandatory.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: