I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!".
We're actively harming the user experience (and driving paying customers away) because of some "expert" advice.
Also the computer itself solves this problem for you in many cases, a guest profile typically deletes all browser session info when you log out.
Many sites? Probably.
You're assuming people log out reliably or otherwise behave in the most secure way. They don't.
I also don't see how logging out/killing a session after 15 minutes of inactivity is much of a hardship for the user.
And it's not just extremely annoying, it's also completely unnecessary. Just put a "trust this browser" checkbox on the sign-in page and adjust the session timeout accordingly.
That works. It defaults to the "safe" behavior, but allows users to self-select into other behavior that they find less objectionable.
FWIW, my end-users are using public computer labs, so we have to build for the worst-case in terms of user security habits.
I'm not really sure what the best fix is; there are many possible ones. I've seen total clowns pushing decades-old nonsense be taken seriously by competent businesses simply because they thought "hiring an expert" was enough, like they're a plumber or something.
I think that’s a big difference.
I believe there was an article on HN recently about a startup that used a "lawyer" that wasn't because they didn't check their credentials after getting a great reference. Just because there are consequences doesn't mean it doesn't happen.
I feel quite certain that I haven't, I just think the point is poorly made and I've spoken specifically to why I think that to be the case. You can get all the recommendations and referrals you want for an infosec professional; nothing stops that person from holding themselves out to be such a professional, quality of work or competency performing it notwithstanding.
You can absolutely suck as a pentester, but still legally hold yourself out to be one and advertise yourself as one to anyone who will hire you.
You can NOT do the same, holding yourself as an attorney or a doctor without very real risk of legal action if you are in fact-not licensed to do either. There are bar associations and medical boards governing various aspects of their work, and how their work is conducted, performs ethics and competency investigations on license holders, and can take away their license to continue working in such capacity if said investigations deem fit. No such governing board or ethical board exists for infosec professionals.
That is a pretty important difference that shouldn't be ignored just to make a petty point about how easy is is to ask for a referral.
Just because there are consequences doesn't mean it doesn't happen.
Which is only supplemental to all of this. My entire point is that it happens, and the prudent do the diligence to make sure it doesn't.
People who are wrong usually do.
> You can get all the recommendations and referrals you want for an infosec professional; nothing stops that person from holding themselves out
Here is where you missed the point.
You are correct that we do not license, say, pen testers the same way we license doctors. You are incorrect in thinking that this matters.
The point is that in both cases, reputation is the best general-purpose measure of who you want. That's all.
My mentioning certs may have steered you wrong, and that was a bit of a distraction. My point there was that certs tell us something, usually not much, but are still better indicators than their self-advertising.
Does reputation matter? Yes. This I will openly concede. Do I think credentials are meaningless? No.
Where we disagree is "thinking that this matters". I still think it absolutely does, and think the analogy is a poor one. You clearly think it doesn't, that's fine, but I don't think it makes either one of us less or more wrong. Perhaps that's all there is at play here, a difference of opinion in how an organization prosecutes the search for a qualified expert in security, medicine or law; and I think it's revealingly disingenuous to frame such organizational decision making and risk tolerances when seeking professional services with rigid and inflexible absolutes of "right way" or "wrong way" or whether or not method A matters whereas method B doesn't.
When I was a kid, a teacher told me learning was supposed to be hard and unpleasant, and I believed her for a long time. Only when I started enjoying myself in spite of that did I see it was wrong, and I started doing well in school, and (more importantly) pursuing my own interests.
There's a similar thing with security - people assume good security must be painful, so making it painful becomes a goal. Sometimes this is sincere, sometimes (TSA) intentional theater. But either way, the result is intentional hostility to the people who use the system.
I'd bet money they have a one-sentence answer for why it does each of those things ("order is scrambled to prevent shoulder-surfing"), but have done zero testing to determine whether those theories are correct.
Another favorite of mine are password conposition rules, which do nothing but reduce security and are everywhere :(
The client can only use numerical passwords. When loading the login page, their site also loads the number pad, which consists in an HTML pad containing the 10 digits. The digits are displayed as base 64 images and in a random order, so it's impossible to determine which digit is which from parsing the HTML alone. In the HTML, the images of the digits are each associated to a random 3 letters string. This string will be sent to the server instead of the plain digit.
With the number pad, the site also load a "challenge", and this challenge is sent to the server when connecting. My guess is that this challenge is an encrypted string that indicates what digit corresponds to what 3 letters string.
I made a script that logs in to my bank account to get some information and I was able to do it without using OCR on the images of the number pad because the images never change, so their base 64 strings are always the same. I was a bit disappointed when I realized it, I thought that the people who came with such a twisted login form would have added random noise to the image, just for fun.
Weeeeeelll...
I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS.
Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.
A second factor is something you have, i.e. your phone, a hardware token, or access to a shared secret you don't store in your head.
Password managers kind of mangle the idea and turn the password from something you know to something you have.
The idea of "something you have" is that the thing can't be duplicated. As soon as it can, it's no longer "something you have". Any number of people might have it. A person who has it might not be you.
SMS hijacking, for example, converts your phone-based authentication to a password, where the password is your phone number. (Since an attacker who knows that number can pass the test.)
TOTP starts its life as a password.
It seems to me you are ascribing properties to "something you have" that aren't warranted. The "something you have" needs to prove you were party to the initial exchange, not necessarily that you were the only one present -- that's why we use two factors, and not only TOTP.
> The "something you have" needs to prove you were party to the initial exchange
This is not something that can be proven at all. Accordingly, proving it is not a goal. Anything that can be had can also be transferred. Your delegated agent's login attempt is just as valid as yours is.
Sms hijacking doesn't "convert" anything anymore than someone with a telephoto lens "converts" an old-style hardware token to a password. (Yes, I know the p in otp is password, and called that because it's entered by the user. It's not a password in terms of a factor you "know" because it's time-limited.)
These are also fluid ideas that are used to describe roughly different failure modes for different types of authentication:
Passwords are thought of as things the user can disclose.
Totp and other "second factors" are thought of as things that must be stolen, or if disclosed have a very short viability time.
Biometric are things that can't be disclosed, but can be lost, and (and when properly implemented) not stolen.
You're trying to argue that these categories of authentication factors have hard lines and definitions when they're fluid categories being used to think about failure modes of a method. Each specific authentication method has its own strengths and weaknesses.
Also, sms hijacks require a lot more than simply "knowing" a phone number. While sim cloning and ss7 attacks are known and very possible, they're still fairly complex. You can also social engineering tech support at phone companies to activate your sim for an account, but that is also significantly more difficult than simply "knowing" a phone number and also a failure of the authentication the phone carrier is using.
TOTP gets set up in the first place when the website discloses your seed to you. It's not something that can't be disclosed. Seeds get disclosed all the time; workflows are built around it.
> Biometric are things that can't be disclosed
Huh?? Biometrics are things that it's impossible to avoid disclosing. If you're ever in a police station, they are free to sample your DNA. You shed it all over the place. If you ever handle something, you just disclosed your fingerprints. If there are any pictures of you out there, your face is public information.
> sms hijacks require a lot more than simply "knowing" a phone number.
I didn't claim otherwise. The intent of my sentence above is to say that a context which involves a working hijack attack converts an SMS challenge from a second factor into a password. If your attack is working, knowing the phone number is sufficient to authenticate as the victim.
I didn't notice this sentence before. Compare the issue of releasing photographs of master keys.
https://www.schneier.com/blog/archives/2012/10/master_keys.h...
Compare the (correct) comment from that post:
> the press has helpfully published a photograph of the keys, so you can make your own, even if you didn’t win the eBay auction.
with this official statement from the government of New York:
> “If you’re selling it, it’s in your possession for an unlawful reason,” said City Councilmember Elizabeth Crowley, chairwoman of the Fire and Criminal Justice committee.
( https://nypost.com/2015/09/20/the-8-key-that-can-open-new-yo... )
Saying "you're not supposed to have this" won't stop people from having it. These keys are regulated as if they are "something you have", but the facts are otherwise.
Similarly, they can grab the shared secret from the server.
It’s marginally better than a password manager (though some of those support TOTP now), since they can’t pull all your credentials by keylogging your master password.
Would you not install two deadbolts on your door if you needed the extra security?
The hash seed that generates a password is connected to the device.
In fact, in Google Authenticator you can even conveniently export all running TOTP to another Google Authenticator without any connection with the apps or anything else whatsoever.
I was in total agreement with him - you can in theory run the algorithm by hand.
It isn't especially relevant though - 2-factor is "something you know, something you have". You need to have the hash.
All I need for password authentication is the password and a device that can generate a one time proof that I know the password.
TOTP just seems more secure because the password is never displayed to the end-user.
A password/passphrase/passcode is something you know.
A hash for a TOTP is something you have. 2 factor means something you know and something you have (or something you are): https://dis-blog.thalesgroup.com/security/2011/09/05/three-f...
(And yes in theory you could remember the hash, and have a custom TOTP client that lets you enter it in. But unless you do this it is a theoretical argument only).
Indeed, this is an argument you can reasonably make.
> TOTP is no more a password than whatever one-time code you'd get by SMS.
But this isn't; this is just a blatant lie.
I see this view a lot. It's wrong. TOTP is fundamentally different to a password, as the stored "password" (by which I presume you mean the key) is never transmitted anywhere.
TOTP in fact has one property that makes it potentially* the most secure of all 2FA methods: it can be used airgapped. As the credential you type into the 2FA form is not the saved secret.
* I say "potentially" because the relative inconvenience + human factors conspire to make it less secure than e.g. U2F in most cases. But assuming hypothetical perfect conditions, there would be nothing more secure than TOTP for 2FA.
Are you familiar with SRP?
TOTP has all of the properties of passwords, and no properties that passwords don't have. That makes it... a password.
I would say SRP is strictly a misnomer (though it's a useful conflation). Generally speaking password is a value provided for authentication (if it's no longer being "provided", as in SRP, it's something different... but I understand using a familiar word for that something different is helpful when communicating).
Either way, in saying TOTP was "just a password", the point you were trying to make was that TOTP is "no different than and therefore no better than a 2nd traditional password". The fact it's not transmitted makes it very different to, and better than, a traditional password. So whatever you want to define the definition as, the point stands.
> and no properties that passwords don't have
It has 1 property that passwords don't have: it is not transmitted!
TOTP is a password. The fact that it is a password doesn't matter though since it is something you have (and can't know) which augments the something you know. This satisfies the intent of MFA.
It kills me that most enterprise environments use Kerberos via Active Directory, LDAP, or NIS. So, your workstation probably has Kerberos tickets sitting on it, which would allow very light weight 2-way authentication and encryption of internal flows.
TLS client certificates and TLS-everywhere would be another good option, but it's particularly frustrating that the Kerberos TGTs are already on the client machines. The key management part is already solved in the Kerberos case.
Kerberos is even potentially resistant to quantum cracking. (Grover's quantum search algorithm effectively halves the key size of ideal symmetric ciphers, so you'd want 256-bit keys.) Forward secrecy is an issue, but there are proposals to incorporate DH key exchange in the pre-auth to give imperfect forward secrecy. A post-quantum key agreement protocol, like RLWE would be fairly strait forward to incorporate, with standardization being the main hurdle.
Part of the problem is that it's "enterprise" tech, which means all sorts of "enterprise" middleware claims to support it with some half-assed concoction that worked on the presales demo environment once, back in 2001, and nobody else has touched since. And it's also old and pretty obscure, with documentation lost to the fog of time, and very few people who remember how it was supposed to work - a bit like MS DCOM...
The "Password" named in "Time-based One Time Password" is the temporary generated value you transmit. It's not what's stored on the TOTP device, so in the context of this discussion, that temp value isn't what the gp was referring to.
Careful; "one-time password" is in the name, and it certainly isn't that. Your TOTP seed stays valid forever.
Slight detail that’s of course completely irrelevant.
You realize that, out of the many comments I've made in this tree, the one you responded to was the one that said
> Are you familiar with SRP?
There are more ways of compromising someone's information than capturing it in transit. If you give me your phone, I can read your TOTP seeds straight out of Google Authenticator.
You’d need to type a nonce into the dongle, then type the result into your computer.
TOTP is just a password. Also, in practice, the server has to have non-air-gappped access to a TOTP generator, so it’s not really air gapped at all.
Read up on the great RSA key fob recall for an example of TOTP-style auth gone horribly wrong.
> You’d need to type a nonce into the dongle, then type the result into your computer.
That would be a cool augmentation of digest auth, but afaik is hypothetical currently (at least as far as common use goes). I can use TOTP airgapped right now.
> in practice, the server has to have non-air-gappped access to a TOTP generator
This is a fair point, but requiring full server compromise is still a nice step up from being mitm-able.
> so it’s not really air gapped at all
That seems like a rather extreme conclusion to draw. Client-side only air gapping is still airgapping, the fact it doesn't extend to protection from server compromise doesn't completely invalidate the benefits.
After the security backlash they now backpedaled and implemented 2FA with ONLY apps. Apps that ONLY work on iOS and Google Android. I had endless calls from family where they couldn't access their banks anymore because they had a Huawei phone or a dumb phone. Banks are citing "security" as explanation why they can't use smartcards, hardware tokens or even bring apps to desktop computers or phones without Google services.
The funny part is - ALL banks did this at once. Why? Because the security consultants had "must have app" and "must check Google Safety net" on their check lists.
What country are you taking about? In regards to the EU 2FA thingy I start to belief to see a pattern. In countries who had established online banking standards with 2FA, nothing changed. But countries without, went ballistic. SMS or App only 2FA on every login and on every transaction. Yah, I can see that this is annoying.
While for me with my German banks I still access them using the FinTS protocol with a banking software of my choosing. For transaction above 20€* I need a TAN from my chipTAN/Sm@rt-TAN device (Which shows you the transaction details). Optional I could choose an app. SMS was phased out years ago (By my banks. Others perhaps still have it.)
(*only 3 transaction a day I believe. You can deactivate that so that you get asked for a TAN every time.)
It's a minor inconvenience for someone who is organised or is used to store secretes securely but a complete nightmare (including a security nightmare) for your average Joe.
Thanks EU, thanks governments for your precious regulations that keep us safe.
I wonder how many similar stories there are in fields I'm not an expert of.
I talked with fintech founders and they mostly say "sure, we could give better user experience and then have a fight on our hands with auditors because we didn't fill out all the checkboxes from the reputable security consultancy that 'interprets' the requirements"