First published on MSDN on Jun 15, 2018
Microsoft announced a while ago that passwordless authentication is coming to Windows 10. Sjoukje also brought it to attention on this blog:
http://blogs.msdn.microsoft.com/azuredev/2018/04/26/azure-content-spotlight-password-less-sign-in-to-azure-windows-10/
Having "unboxed" two new Yubikeys I decided to do an introductory post on the topic. Well, more like a mini Q&A really.
While the announcement was clear enough in the message "let's get rid of passwords", some of the details weren't really described in full.
While "passwordless" is an understandable term this is not the technical name for it though. The term for what a browser needs to support would be WebauthN, but the more generic term (which also includes non-browser support) is FIDO2. You might also see references to UAF, U2F, etc. which are part of the FIDO standards so they are related, but not the same thing.
Does this mean that I just plug a Yubikey or a similar device into my computer, and I don't have to type passwords again?
No, not yet. On a high-level you have two password-based contexts in Windows. You have the system part of it which includes logging in to Windows, running apps and processes, etc.
The other part is web-based apps where you sign in to "things" in the browser.
Of course - native apps that you install may have their own login mechanisms, which may include supporting Yubikeys, but that doesn't count as "part of Windows" in the traditional sense.
The first part relies on two subcomponents - your Windows build needs to have the necessary bits in the operating system, and the system that stores your credentials also needs to understand the passwordless protocols.
The web-based part relies on your browser supporting the protocols, and does not have a dependency to Windows.
Logging into Windows
Windows computers can be joined to domains or be stand alone. (With stand alone I mean creating local accounts. While signing in with a consumer Microsoft account does not require a domain it is part of a larger identity system.) I have no indications that passwordless will be supported in the stand-alone mode, so until MSFT decides to bring a fully fledged "identity story" for single user setups we'll ignore that part.
The domain join in Windows can be based on either Azure AD or AD. Azure AD will have updates in the cloud to enable this, (as long as you have a compatible client version), but no indications have been given as to the time frame. Currently it is only available in private previews.
Classic AD does not support the necessary protocols and my personal opinion is that I don't see this changing. It would require a whole lot of re-engineering so it would not make sense to implement in current Windows Server versions. Of course, it is no secret that there is an upcoming Windows Server 2019 release, but my guess would still be that if such support was added to on-premises environments it would be through ADFS. ADFS already supports modern protocols like OAuth and OpenID Connect so the basics are in place already. I don't know though, and for now it seems cloud is the way to go for OS-level passwordless support.
But I do passwordless login on my Surface already - it's called Windows Hello and uses my webcam!
Yes, that is of course a valid point. I love sitting down and being logged in just by looking at my computer. (Depending on the timing and viewing angle it sometimes unlocks while I'm pulling out my chair, so by the time I sit down the process is completed.) So, it is entirely possible that those who have this option will prefer to use what they have instead of changing to this new feature. Windows Hello isn't specific to facial recognition though, it is a framework so FIDO2 support will also integrate into the same mechanism.
Ok, enough with the Windows login - what about browsers?
As of writing this Firefox and Chrome are the only major browsers to support WebauthN. I expect Edge to support this in due time, but unfortunately Microsoft has not given us much details on this either.
On the topic of Yubikeys... How is this different than the USB/NFC dongles I already have?
The existing dongles are designed to work as multi-factor auth mechanisms. You authenticate with a primary factor first, and then you use your dongle at a later point in the process. While the flexibility of the Yubikeys means that you can implement your own passwordless authentication it isn't a standardized secure way for achieving this. And for instance using ADFS it is easy enough to write your own plug-in for additional factors, but you cannot replace the primary factor with a "passwordless" device. The new standard, and the new dongles, have been developed to address the primary factor scenario.
This doesn't sound like a security improvement to me - if someone steals my dongle they can impersonate me!
It's all about understanding the use case, the different threat vectors involved, and acting accordingly. Clearly your bank will not be ready to accept passwordless authentication any time soon for your online banking.
Continuing the bank analogy we see that a large portion of fraud occurs when someone steals your credit card number as not all online shops need more than a number and expiry date to process your purchase. Same thing with your online accounts - most of them are compromised by getting hold of your credentials.
Passwordless will thwart ordinary username/password combo attacks, as the cryptography involved ensures you don't have a password to share.
When someone steals your credit card they usually need to acquire your pin code as well, as the card itself is not enough. Ok, someone will eventually chime in about RFID chips in cards. Yes, I have that too. The way it works is that for transactions below a set threshold I can just wave my card near the terminal, but for higher valued transactions I need to authenticate with my PIN. So, I can buy a beer with a stolen card, (even if beer is pricey in Norway), but I can't buy a new iPhone.
Same with passwordless dongles. You can still enforce multi-factor auth, and you can even have an actual password as such a mechanism if you so choose. You could also use SMS/authenticator apps in addition to the dongle, and so forth.
Short version; yes, passwordless can make for a pretty insecure setup if that is all you rely on, but it is entirely possible to implement secure scenarios as well. And frankly, some of the breaches over the years have certainly showed us there are plenty of ways to design systems in horribly insecure ways without ever involving a FIDO standard.
So, how can I actually test this?
Well, hardware would obviously be a pre-req. Since Firefox/Chrome supports it you could install that for the software side of things. Thing is - websites will not just magically work with WebauthN. The site must be modified to support it. For now you can test with the https://webauthn.org demo site if you don't want to write your own code.
I would love to do a proper code sample myself, but for now it's more important to have a basic grasp of the bits and pieces that are involved than implementing stuff you're only able to run in your own lab :)
I hope this cleared up some questions you might have had, even though it's not easy when things are so vague from the provider side of things. I'll certainly have a look at what can be done to make my logins smoother in the future.
Authored by Andreas Helland
Microsoft announced a while ago that passwordless authentication is coming to Windows 10. Sjoukje also brought it to attention on this blog:
http://blogs.msdn.microsoft.com/azuredev/2018/04/26/azure-content-spotlight-password-less-sign-in-to-azure-windows-10/
Having "unboxed" two new Yubikeys I decided to do an introductory post on the topic. Well, more like a mini Q&A really.
While the announcement was clear enough in the message "let's get rid of passwords", some of the details weren't really described in full.
While "passwordless" is an understandable term this is not the technical name for it though. The term for what a browser needs to support would be WebauthN, but the more generic term (which also includes non-browser support) is FIDO2. You might also see references to UAF, U2F, etc. which are part of the FIDO standards so they are related, but not the same thing.
Does this mean that I just plug a Yubikey or a similar device into my computer, and I don't have to type passwords again?
No, not yet. On a high-level you have two password-based contexts in Windows. You have the system part of it which includes logging in to Windows, running apps and processes, etc.
The other part is web-based apps where you sign in to "things" in the browser.
Of course - native apps that you install may have their own login mechanisms, which may include supporting Yubikeys, but that doesn't count as "part of Windows" in the traditional sense.
The first part relies on two subcomponents - your Windows build needs to have the necessary bits in the operating system, and the system that stores your credentials also needs to understand the passwordless protocols.
The web-based part relies on your browser supporting the protocols, and does not have a dependency to Windows.
Logging into Windows
Windows computers can be joined to domains or be stand alone. (With stand alone I mean creating local accounts. While signing in with a consumer Microsoft account does not require a domain it is part of a larger identity system.) I have no indications that passwordless will be supported in the stand-alone mode, so until MSFT decides to bring a fully fledged "identity story" for single user setups we'll ignore that part.
The domain join in Windows can be based on either Azure AD or AD. Azure AD will have updates in the cloud to enable this, (as long as you have a compatible client version), but no indications have been given as to the time frame. Currently it is only available in private previews.
Classic AD does not support the necessary protocols and my personal opinion is that I don't see this changing. It would require a whole lot of re-engineering so it would not make sense to implement in current Windows Server versions. Of course, it is no secret that there is an upcoming Windows Server 2019 release, but my guess would still be that if such support was added to on-premises environments it would be through ADFS. ADFS already supports modern protocols like OAuth and OpenID Connect so the basics are in place already. I don't know though, and for now it seems cloud is the way to go for OS-level passwordless support.
But I do passwordless login on my Surface already - it's called Windows Hello and uses my webcam!
Yes, that is of course a valid point. I love sitting down and being logged in just by looking at my computer. (Depending on the timing and viewing angle it sometimes unlocks while I'm pulling out my chair, so by the time I sit down the process is completed.) So, it is entirely possible that those who have this option will prefer to use what they have instead of changing to this new feature. Windows Hello isn't specific to facial recognition though, it is a framework so FIDO2 support will also integrate into the same mechanism.
Ok, enough with the Windows login - what about browsers?
As of writing this Firefox and Chrome are the only major browsers to support WebauthN. I expect Edge to support this in due time, but unfortunately Microsoft has not given us much details on this either.
On the topic of Yubikeys... How is this different than the USB/NFC dongles I already have?
The existing dongles are designed to work as multi-factor auth mechanisms. You authenticate with a primary factor first, and then you use your dongle at a later point in the process. While the flexibility of the Yubikeys means that you can implement your own passwordless authentication it isn't a standardized secure way for achieving this. And for instance using ADFS it is easy enough to write your own plug-in for additional factors, but you cannot replace the primary factor with a "passwordless" device. The new standard, and the new dongles, have been developed to address the primary factor scenario.
This doesn't sound like a security improvement to me - if someone steals my dongle they can impersonate me!
It's all about understanding the use case, the different threat vectors involved, and acting accordingly. Clearly your bank will not be ready to accept passwordless authentication any time soon for your online banking.
Continuing the bank analogy we see that a large portion of fraud occurs when someone steals your credit card number as not all online shops need more than a number and expiry date to process your purchase. Same thing with your online accounts - most of them are compromised by getting hold of your credentials.
Passwordless will thwart ordinary username/password combo attacks, as the cryptography involved ensures you don't have a password to share.
When someone steals your credit card they usually need to acquire your pin code as well, as the card itself is not enough. Ok, someone will eventually chime in about RFID chips in cards. Yes, I have that too. The way it works is that for transactions below a set threshold I can just wave my card near the terminal, but for higher valued transactions I need to authenticate with my PIN. So, I can buy a beer with a stolen card, (even if beer is pricey in Norway), but I can't buy a new iPhone.
Same with passwordless dongles. You can still enforce multi-factor auth, and you can even have an actual password as such a mechanism if you so choose. You could also use SMS/authenticator apps in addition to the dongle, and so forth.
Short version; yes, passwordless can make for a pretty insecure setup if that is all you rely on, but it is entirely possible to implement secure scenarios as well. And frankly, some of the breaches over the years have certainly showed us there are plenty of ways to design systems in horribly insecure ways without ever involving a FIDO standard.
So, how can I actually test this?
Well, hardware would obviously be a pre-req. Since Firefox/Chrome supports it you could install that for the software side of things. Thing is - websites will not just magically work with WebauthN. The site must be modified to support it. For now you can test with the https://webauthn.org demo site if you don't want to write your own code.
I would love to do a proper code sample myself, but for now it's more important to have a basic grasp of the bits and pieces that are involved than implementing stuff you're only able to run in your own lab :)
I hope this cleared up some questions you might have had, even though it's not easy when things are so vague from the provider side of things. I'll certainly have a look at what can be done to make my logins smoother in the future.
Published Feb 13, 2019
Version 1.0
