Presumably this allows them to change the confidence statistics for logins, so that, e.g., SMS 2F is considered more likely to be an attacker. SMS 2F from a different location to a previous certificate/FIDO2 login might be denied or alerted.
Also, they’re trying to force people into using the Microsoft Authenticator, which is an active telemetry collector, vs e.g. Google Authenticator, which is 100% offline and TOTP only.
Headline is certainly attention grabbing but not as bad as it sounds.
This is, currently, for commercial customers only and will always pick the most secure option that your account has setup. If the most secure option is not available, they'll go the next one. This generally makes sense.
Obviously, I'd prefer if you can pick and choose the order, but then again it's Microsoft so I'm not surprised whatsoever.
The Register tends to do good reporting. They absolutely have a mocking and disrespectful tone to them, and love an inflammatory headline, but that's just style.
> Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors will store biometric data on the fingerprint module instead of in the database file.
So, knowing how most "enterprise" pcs get the cheapest possible implementation, I'd bet that in most cases windows stores the biometric data itself.
Google has done something similar; they make it hard to use my preferred 2FA app ("Authenticator" for iPhone). In order to add it I had to pick a different thing, then add 2FA, then remove the other thing. And even with that, it still tries to get me to authenticate with one of their apps on one of my iThings, de-emphasizing the option to just put in my code.
Dunno why these companies are like this, is there a good-faith explanation? Maybe they have a lot of support problems with authenticator apps?
Getting your app on more phones means more access to data. Not sure if that explanation is good-faith, but that’s the explanation. Same reason all sorts of websites try to force their apps on you
Because 3rd party 2FA apps are inherently untrustworthy. To Google, even Microsoft Authenticator is a security risk because to use it you have to give it the TOTP seed for your account. So Google (and Microsoft) would rather you use their solutions that let them push the prompt to you and ensure that it's a known device responding. It's still not a perfect solution, but it still is a more secure option.
This is a terminology problem the industry is having right now, but I think you're conflating the general concept of 2FA with the specific concept of TOTP-based 2FA. It's not about the open sourceness per se, it's about the fact that a TOTP secret can be shared far and wide, but a push-based 2FA prompt is targeted to a specific device. While this no more than anything else "guarantees" security, it closes down a lot of vectors, especially around TOTP tokens being stolen unknowningly. I'm likely to notice if my device is missing, and while in theory Google's systems can be compromised to redirect the request or duplicate the request or accept false approvals, a lot more of that is under their control, design, and monitoring than a TOTP token out in the wild.
I've never really liked TOTP. Its security characteristics aren't really that far off of a password and I've never been convinced it constitutes a true "second factor" as a result. I notice my password manager even has a slot to store them in now, which kind of further proves my point; if my system for storing "things I know" (as opposed to "things I have" and "things I am") can store both my password and my TOTP token, it rather seems as if I've got two "things I know" and not two separate factors. So I'm not even terribly convinced TOTP should be considered a "second factor" anyhow. The attempt to use it to turn devices into a "thing I have" relies too much on the user which rather defeats the purpose. So I kind of hope to see TOTP to slowly but surely not be even considered 2FA at all, which should help resolve this terminology confusion... eventually, sometime in the next decade or so.
TOTP is a significant improvement over passwords, even if you store them in a vault alongside your passwords.
Is it as good as a separate dongle or push notification? No, it isn't in terms of device verification. But it is more convenient. Unlike a password, TOTP secrets never have a reason to leave your vault once you have stored them. One thing I dislike about push notifications is the possibility for fatigue attacks. Even if you only get one from an attacker, a fat-finger could provide access to your account. Oops!
If you are using a vault properly, even leaking the master password is not enough for an attacker to break in. They also need a copy of the vault. Or they'd need to have compromised a device on which you actively use the password safe (but that's tough to defend against).
To me, TOTP seems like a good middle ground. It isn't vendor locked. Unlike biometrics, TOTP secrets can be changed. TOTP gives users the power to choose how secrets are stored and how one-time-passwords are presented.
That's the main sticking point for a lot of big companies. There are loads of authenticator apps able to store TOTP secrets, and it's opaque to them whether the user is using a secure implementation, handling their TOTP secret safely, etc. While with a push notification they have complete control over that process.
In the end, how secure a user is being isn't really their business. How much paternalism from these companies is too much?
I am really happy that I don't use these companies services personally, so I don't have to be subjected to their whims. My employer does, but that's their choice.
I think you misunderstand my point. It has nothing to do with the ongoing debate about whether or not passwords are good or bad and should be superseded by some other approach. It has to do with whether or not it's a second factor.
To remind people, though I alluded to it in my post, the factors are: A thing you know, a thing you are, a thing you have. A second factor must not merely be an additional thing in the same category, it must be in a separate category. (Otherwise we could increase security simply by requiring that the user input six passwords instead of just one.)
My objection is that TOTP is still fundamentally a thing you know. The fact that my "thing I know" store (more typically called a "password manager") can store them is strong evidence, if not proof, of this fact.
Your argument in a way further reinforces that point. If they're better passwords than passwords, hey, by all mean make users log in through a TOTP token and skip the password entirely. But that's exactly the problem! It is sufficiently passwordlike for this to be a valid possibility.
The rest of the frippery around TOTP that tries to turn it into a "thing you have" are all on the client side, and thus, security theater. Google Authenticate making it a pain to get my secrets out wasn't actually security (and they had to let it out anyhow because when people upgrade phones they don't want to have to rotate dozens of tokens). It was a "thing I know" every bit as much as my password to my bank is a "thing I know", despite the fact I don't actually "know" it in the sense that it is in my memory. I have no idea what my bank password is. But the things stored in my password manager and the things I can store in my password manager are all "things I know". I can't store a thing I am [1] or a thing I have in my password manager. Being able to store them in my thing-I-know manager shatters the illusion that this is about a thing-I-have.
Push notifications to specific phones aren't perfect but they are a lot closer to a "thing I have".
[1]: I mean, in principle. Certainly I can store the things that I am in my password manager. However if my password manager could present my fingerprint directly that would generally be considered some sort of security violation. That said, I'm not a big fan of "thing I am" in general precisely because while it may work when everyone's honest, who cares about the characteristics of a security system when that's the case? In case of active attack, "thing I am" degenerates to "thing I know" because it will always be possible to fake it if I know it, generally quite practically for any feasible consumer solution. Only super high security installations can justify the degree of expensive hardware necessary to do good checks of "thing I am". And if it degenerates to "thing I know", it further degenerates to "thing I know that I also can never change", which means that biometrics are actually much worse for security than the traditional "thing I know" until possibly quite high on the expense curve for the biometrics hardware and invasiveness.
excited at the prospect of there possibly being a viable way out of corporate-hosted 2FA solutions, I clicked into the repository and checked out the linked "About Me", and was met with:
Your connection is not private
Attackers might be trying to steal your information from mattrubin.me (for example, passwords, messages, or credit cards). Learn more
In order to use OTP with google I had to setup a security key. and then every time I login it will ask for the key, I have to cancel the request in the browser, it will say something went wrong and then let me select the option to use my OTP.
I have that enabled too. Now I can no longer RDP into my computers or connect to fileshares as those do not support passwordless accounts. It been like that for years, since MS introduced first passwordless Microsoft Accounts.
37 comments
[ 1.6 ms ] story [ 73.1 ms ] threadLet you use a different method you signed up for.
Also, they’re trying to force people into using the Microsoft Authenticator, which is an active telemetry collector, vs e.g. Google Authenticator, which is 100% offline and TOTP only.
This is, currently, for commercial customers only and will always pick the most secure option that your account has setup. If the most secure option is not available, they'll go the next one. This generally makes sense.
Obviously, I'd prefer if you can pick and choose the order, but then again it's Microsoft so I'm not surprised whatsoever.
According to ms's docs, depending on the sensor implementation, the OS might have access to that data:
https://learn.microsoft.com/en-us/windows/security/identity-...
> Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors will store biometric data on the fingerprint module instead of in the database file.
So, knowing how most "enterprise" pcs get the cheapest possible implementation, I'd bet that in most cases windows stores the biometric data itself.
I suspect it is more likely the driver and Windows has no real visibility into it.
Dunno why these companies are like this, is there a good-faith explanation? Maybe they have a lot of support problems with authenticator apps?
When it comes to 2FA, I would rather trust open source apps vs the ones made by Google/MS.
I've never really liked TOTP. Its security characteristics aren't really that far off of a password and I've never been convinced it constitutes a true "second factor" as a result. I notice my password manager even has a slot to store them in now, which kind of further proves my point; if my system for storing "things I know" (as opposed to "things I have" and "things I am") can store both my password and my TOTP token, it rather seems as if I've got two "things I know" and not two separate factors. So I'm not even terribly convinced TOTP should be considered a "second factor" anyhow. The attempt to use it to turn devices into a "thing I have" relies too much on the user which rather defeats the purpose. So I kind of hope to see TOTP to slowly but surely not be even considered 2FA at all, which should help resolve this terminology confusion... eventually, sometime in the next decade or so.
Is it as good as a separate dongle or push notification? No, it isn't in terms of device verification. But it is more convenient. Unlike a password, TOTP secrets never have a reason to leave your vault once you have stored them. One thing I dislike about push notifications is the possibility for fatigue attacks. Even if you only get one from an attacker, a fat-finger could provide access to your account. Oops!
If you are using a vault properly, even leaking the master password is not enough for an attacker to break in. They also need a copy of the vault. Or they'd need to have compromised a device on which you actively use the password safe (but that's tough to defend against).
To me, TOTP seems like a good middle ground. It isn't vendor locked. Unlike biometrics, TOTP secrets can be changed. TOTP gives users the power to choose how secrets are stored and how one-time-passwords are presented.
That's the main sticking point for a lot of big companies. There are loads of authenticator apps able to store TOTP secrets, and it's opaque to them whether the user is using a secure implementation, handling their TOTP secret safely, etc. While with a push notification they have complete control over that process.
I am really happy that I don't use these companies services personally, so I don't have to be subjected to their whims. My employer does, but that's their choice.
To remind people, though I alluded to it in my post, the factors are: A thing you know, a thing you are, a thing you have. A second factor must not merely be an additional thing in the same category, it must be in a separate category. (Otherwise we could increase security simply by requiring that the user input six passwords instead of just one.)
My objection is that TOTP is still fundamentally a thing you know. The fact that my "thing I know" store (more typically called a "password manager") can store them is strong evidence, if not proof, of this fact.
Your argument in a way further reinforces that point. If they're better passwords than passwords, hey, by all mean make users log in through a TOTP token and skip the password entirely. But that's exactly the problem! It is sufficiently passwordlike for this to be a valid possibility.
The rest of the frippery around TOTP that tries to turn it into a "thing you have" are all on the client side, and thus, security theater. Google Authenticate making it a pain to get my secrets out wasn't actually security (and they had to let it out anyhow because when people upgrade phones they don't want to have to rotate dozens of tokens). It was a "thing I know" every bit as much as my password to my bank is a "thing I know", despite the fact I don't actually "know" it in the sense that it is in my memory. I have no idea what my bank password is. But the things stored in my password manager and the things I can store in my password manager are all "things I know". I can't store a thing I am [1] or a thing I have in my password manager. Being able to store them in my thing-I-know manager shatters the illusion that this is about a thing-I-have.
Push notifications to specific phones aren't perfect but they are a lot closer to a "thing I have".
[1]: I mean, in principle. Certainly I can store the things that I am in my password manager. However if my password manager could present my fingerprint directly that would generally be considered some sort of security violation. That said, I'm not a big fan of "thing I am" in general precisely because while it may work when everyone's honest, who cares about the characteristics of a security system when that's the case? In case of active attack, "thing I am" degenerates to "thing I know" because it will always be possible to fake it if I know it, generally quite practically for any feasible consumer solution. Only super high security installations can justify the degree of expensive hardware necessary to do good checks of "thing I am". And if it degenerates to "thing I know", it further degenerates to "thing I know that I also can never change", which means that biometrics are actually much worse for security than the traditional "thing I know" until possibly quite high on the expense curve for the biometrics hardware and invasiveness.
Your connection is not private
Attackers might be trying to steal your information from mattrubin.me (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_DATE_INVALID
we can't win :,(