Microsoft ruined passwords, now aims for a passwordless future(puri.sm)
puri.sm
Microsoft ruined passwords, now aims for a passwordless future
https://puri.sm/posts/microsoft-ruined-passwords-now-aims-for-a-passwordless-future/
317 comments
SQRL seems like a good option that incorporates public/private keys as an alternative to passwords
> Passwords must be shared to work, therefore they can never truly be secret.
That's not entirely true, as demonstrated by constructions like PAKE. It is a shame, though, that the adoption is almost nonexistent.
That's not entirely true, as demonstrated by constructions like PAKE. It is a shame, though, that the adoption is almost nonexistent.
That's probably an interesting lesson in its own right: PAKE originated in the early 90s and if it's still facing adoption barriers that suggests that the model is fundamentally untenable.
Not really. Compare https://www.johndcook.com/blog/2008/03/25/innovation-ii/
An English captain ran a private experiment in 1601 to see what happened when sailors were fed lemon juice. The group receiving lemon juice had zero cases of scurvy. The group not receiving lemon juice experienced 40% mortality from scurvy.
(Imagine running an experiment today with 40% mortality in the control group!)
The results were reported, but nothing was done with them. The navy had to rediscover the same fact a few hundred years later.
But there was nothing wrong with the model.
An English captain ran a private experiment in 1601 to see what happened when sailors were fed lemon juice. The group receiving lemon juice had zero cases of scurvy. The group not receiving lemon juice experienced 40% mortality from scurvy.
(Imagine running an experiment today with 40% mortality in the control group!)
The results were reported, but nothing was done with them. The navy had to rediscover the same fact a few hundred years later.
But there was nothing wrong with the model.
Deploying the scientific method to decide something looks quite obvious to us in these days of Bill Gate's efforts to inject minute sensors into us all under the guise of vaccination or something 8)
https://www.bbc.co.uk/news/uk-england-37320399 - this is a BBC article about James Lind, who did an experiment in 1747. Not too sure about four ships in 1601 - there are no sources in the link above. Also, he was a Scot, not English. He was of course a Brit too (1707-)
The results probably were reported but they were probably not distributed effectively. Nowadays we have the internet to vilify entire populations, within seconds. Back then, you had to get a pamphlet printed that a few 100 people would read.
"Sailors who ate the ship's rats were inadvertently protecting themselves - as the animal synthesizes its own vitamin C."
So there you go. If you run out of shipmates and lemons: eat the rats!
https://www.bbc.co.uk/news/uk-england-37320399 - this is a BBC article about James Lind, who did an experiment in 1747. Not too sure about four ships in 1601 - there are no sources in the link above. Also, he was a Scot, not English. He was of course a Brit too (1707-)
The results probably were reported but they were probably not distributed effectively. Nowadays we have the internet to vilify entire populations, within seconds. Back then, you had to get a pamphlet printed that a few 100 people would read.
"Sailors who ate the ship's rats were inadvertently protecting themselves - as the animal synthesizes its own vitamin C."
So there you go. If you run out of shipmates and lemons: eat the rats!
https://en.wikipedia.org/wiki/James_Lancaster#Scurvy
The navy is not a decentralized organization. Distribution of the results is not a concern.
The navy is not a decentralized organization. Distribution of the results is not a concern.
"In 1601 Captain Admiral James Lancaster unintentionally performed an experimental study of lemon juice as a preventive for scurvy."
Unintentionally ...
This is in 1747: https://www.bbc.co.uk/news/uk-england-37320399
Unintentionally ...
This is in 1747: https://www.bbc.co.uk/news/uk-england-37320399
The unintentional part was that he had an experimental group and a control group. The experiment itself was not unintentional; he was already aware that the lemon juice should prevent scurvy. That's why the one ship of four that got the lemon juice was the ship he was on.
The fact that the British navy still had no institutional knowledge of scurvy hundreds of years later is the point I'm making. They didn't know how to deal with it despite the fact that a cure had been known for several thousand years, and the navy itself had received James Lancaster's report over a hundred years prior. The navy's behavior reflects nothing other than a very severe failure that would have been trivial to fix at any time.
The adoption barriers that caused the navy to kill thousands upon thousands of its own men over a period of centuries did not reflect any difficulty in preventing scurvy. It was always easy. They reflected the fact that adoption barriers are very large no matter what the context is, and absolutely overwhelming evidence, such as a 100% reduction in the incidence of a disease that ordinarily kills 40% of your manpower, is not enough to bypass them.
The adoption of a practice is at most tenuously related to the effectiveness of a practice. That is not how people adjust their behavior.
What point are you making?
The fact that the British navy still had no institutional knowledge of scurvy hundreds of years later is the point I'm making. They didn't know how to deal with it despite the fact that a cure had been known for several thousand years, and the navy itself had received James Lancaster's report over a hundred years prior. The navy's behavior reflects nothing other than a very severe failure that would have been trivial to fix at any time.
The adoption barriers that caused the navy to kill thousands upon thousands of its own men over a period of centuries did not reflect any difficulty in preventing scurvy. It was always easy. They reflected the fact that adoption barriers are very large no matter what the context is, and absolutely overwhelming evidence, such as a 100% reduction in the incidence of a disease that ordinarily kills 40% of your manpower, is not enough to bypass them.
The adoption of a practice is at most tenuously related to the effectiveness of a practice. That is not how people adjust their behavior.
What point are you making?
we've also had kerberos since the 80s, passwords are never shared it's all digests
> Fortunately we don't need to wonder what to do. WebAuthN is here now and has been ready for a couple years now.
i've only recently started paying attention to this space again, so forgive me if this is a silly question... but does the webauthn standard also include procedures for dealing with a lost, damaged or compromised authenticator device?
i've only recently started paying attention to this space again, so forgive me if this is a silly question... but does the webauthn standard also include procedures for dealing with a lost, damaged or compromised authenticator device?
Nope. Left as an exercise for the user and 2FA provider, and/or the service to provide an alternate recovery system.
so it's pretty much just a standard for having websites present tokens, having browsers talk to authentication devices to sign them, and then shuttling them back to the website?
do the signed tokens reveal anything else about the identity of the user, or just that it's the same user that registered? can tokens that have been signed for two different websites by the same user be linked? (ie: do the public keys or signatures presented to websites a and b tell website a or b about their registration or use of the other site? does the mfa provider learn of the user's identity and registration on sites a and b?)
do the signed tokens reveal anything else about the identity of the user, or just that it's the same user that registered? can tokens that have been signed for two different websites by the same user be linked? (ie: do the public keys or signatures presented to websites a and b tell website a or b about their registration or use of the other site? does the mfa provider learn of the user's identity and registration on sites a and b?)
In a nutshell, you've got the idea. And no: the signed tokens are for all intents and purposes random blobs (often generated literally from /dev/urandom by the server), and the browser strictly associates a WebAuthn keypair to exactly one domain, and no others. Because the browser enforces this, it means it's impossible to phish the user; even if you had the secret key for [email protected] (the music website) you stole from me, you couldn't use it for [email protected] (my bank account).
There is some data you can get from them (Attestation I think is what the spec calls it?) though it's just a optional request response I think, the 2fa can ignore it by itself or at users discretion?
But this data is more about the manufacturing of the 2FA device, and basically amounts to the "bin" it belongs to, like saying built in 2020, as part of batch 3. Vague enough to not really be identifiable, but useful if a flaw in a device is found in a particular model or such.
But this data is more about the manufacturing of the 2FA device, and basically amounts to the "bin" it belongs to, like saying built in 2020, as part of batch 3. Vague enough to not really be identifiable, but useful if a flaw in a device is found in a particular model or such.
No, there's no standard for any of those things. "Lost" or "Damaged" devices at least are indistinguishable from the service POV: you simply cannot authenticate and need to reset your auth method. "Compromised" is a bit different; with WebAuthn you can at least attest that an authenticator device is from some known authority (e.g. this is a valid Apple device), so there's a notion of device authenticity, but this has nothing to do with whether or not the actual device is being used nefariously or with ill intention or not. Maybe you could use it as an anti-fraud signal if you do that stuff.
WebAuthn in a big sense is just a browser-standardized way of a service operator storing your (abstract service users') public key, and you using the private key to sign login challenges from them, proving it is you. Every site gets a different keypair, and that's it in a nutshell. Even though this is not a password, just like any password, a lot of the mechanisms you use to recover from disaster are exactly the ones that are most vulnerable to being attacked.
Any kind of flow to handle these scenarios is basically going to look a lot like how it looks now: Keep emergency recover codes that the user has to print out and use as an extreme emergency, etc. The user has an email attached and you send a magic link to that email in order to do a reset, and it will be assumed this account is secure, and if it's not, then nothing else about the reset scheme really matters. And even if [email protected] is using a password, WebAuthn as a first party feature used by the service operator has a number of real concrete benefits to themselves and the user: no more credential stuffing, browser-enforced phishing immunity, and browsers make it pretty easy to use immediately with features like fingerprint readers or FaceID.
WebAuthn in a big sense is just a browser-standardized way of a service operator storing your (abstract service users') public key, and you using the private key to sign login challenges from them, proving it is you. Every site gets a different keypair, and that's it in a nutshell. Even though this is not a password, just like any password, a lot of the mechanisms you use to recover from disaster are exactly the ones that are most vulnerable to being attacked.
Any kind of flow to handle these scenarios is basically going to look a lot like how it looks now: Keep emergency recover codes that the user has to print out and use as an extreme emergency, etc. The user has an email attached and you send a magic link to that email in order to do a reset, and it will be assumed this account is secure, and if it's not, then nothing else about the reset scheme really matters. And even if [email protected] is using a password, WebAuthn as a first party feature used by the service operator has a number of real concrete benefits to themselves and the user: no more credential stuffing, browser-enforced phishing immunity, and browsers make it pretty easy to use immediately with features like fingerprint readers or FaceID.
so then, as far as i can tell, the only real upgrade, in terms of real security, from the passworded web using password managers, is that under webauthn an individual password cannot be sniffed or phished since it's public key challenge->sign->response.
fixing phishing is a nice big start, but i keep hearing about all these sms redirect attacks and other attacks on password reset functions. leaving that as an exercise to the reader doesn't really seem to solve the problem. (especially in events where all keys must be rotated due to lost/stolen/compromised device)
fixing phishing is a nice big start, but i keep hearing about all these sms redirect attacks and other attacks on password reset functions. leaving that as an exercise to the reader doesn't really seem to solve the problem. (especially in events where all keys must be rotated due to lost/stolen/compromised device)
Well to a first approximation I would say phishing is about 1000x more widespread and dangerous to the average user than SMS-based attacks, so the impact is pretty immediate and significantly larger. I haven't seen any indication of SMS-based attacks (which often require compromises of cell providers or inside jobs, and are often targeted rather than being en masse activities) being in the same league, or even the same sport, as daily phishing attacks. But then again I'm wrong often.
You'll almost certainly never get rid of a long tail of compromises in this area, and some tricky parts will be left up to the service provider to get right (there's nothing stopping someone from bungling the password reset feature, for instance.) But at the end of it all, WebAuthn is here today, it axes multiple major vulnerability classes that are used to compromise accounts globally every day, and any future improvements are going to start from that point.
To be honest, at this point the only people I see hanging onto passwords in 2021 desperately are nothing but computer people like us who have been doing it this way for 20+ years and don't want to change out of stubbornness rather than any kind of actual analysis (this exact dynamic explains a lot of things, actually.) Most normal people already use e.g. federated login mechanisms like FB Login or password managers and don't care if the underlying auth mechanism changes this way.
You'll almost certainly never get rid of a long tail of compromises in this area, and some tricky parts will be left up to the service provider to get right (there's nothing stopping someone from bungling the password reset feature, for instance.) But at the end of it all, WebAuthn is here today, it axes multiple major vulnerability classes that are used to compromise accounts globally every day, and any future improvements are going to start from that point.
To be honest, at this point the only people I see hanging onto passwords in 2021 desperately are nothing but computer people like us who have been doing it this way for 20+ years and don't want to change out of stubbornness rather than any kind of actual analysis (this exact dynamic explains a lot of things, actually.) Most normal people already use e.g. federated login mechanisms like FB Login or password managers and don't care if the underlying auth mechanism changes this way.
> But at the end of it all, WebAuthn is here today, it axes multiple major vulnerability classes that are used to compromise accounts globally every day, and any future improvements are going to start from that point.
and to be honest, i'm glad to see it! it's huge!
i just push back because history tells us that leaving something that big as an exercise to the reader means that it will be gotten wrong and, well, i'm not sure if you really get too many shots at getting the whole web to upgrade authentication methods.
there's been some interesting articles in vice magazine recently where they talk about the expense of mitm'ing someone's text messages only costing about $5. i'm sure as soon as phishing goes away, as a result of something like this, all the fraud will shift to the next easiest weakness, which seems like it would be underspecified standards for resetting one's public keys/credentials/etc.
and to be honest, i'm glad to see it! it's huge!
i just push back because history tells us that leaving something that big as an exercise to the reader means that it will be gotten wrong and, well, i'm not sure if you really get too many shots at getting the whole web to upgrade authentication methods.
there's been some interesting articles in vice magazine recently where they talk about the expense of mitm'ing someone's text messages only costing about $5. i'm sure as soon as phishing goes away, as a result of something like this, all the fraud will shift to the next easiest weakness, which seems like it would be underspecified standards for resetting one's public keys/credentials/etc.
> Any kind of flow to handle these scenarios is basically going to look a lot like how it looks now: Keep emergency recover codes that the user has to print out and use as an extreme emergency, etc.
The worst problem: these recovery codes are not protected from government seizure or theft. A password? I can keep that in my head and, sans government-planted keyloggers or tactical use of a wrench (https://xkcd.com/538/), the government or thief doesn't stand a chance.
The worst problem: these recovery codes are not protected from government seizure or theft. A password? I can keep that in my head and, sans government-planted keyloggers or tactical use of a wrench (https://xkcd.com/538/), the government or thief doesn't stand a chance.
Google's advanced security is a good example of an actual implementation of fido2 where they've had to deal with real world threats and device usage. They require multiple fido2 devices (for dealing with the lost/damaged problems).
Compromise of FIDO2 devices is particularly interesting though. Specialized hardware like a yubikey rather than software based fido2 might help here, but that still leaves theft as a wide open vector. If theft is a risk for your use case, https://www.yubico.com/blog/getting-a-biometric-security-key... could be an interesting solution or using secure hardware on your phone behind a lockscreen. Also having a password (in addition to webauthn) might be good enough for you to slow down an attacker enough for you to disable your compromised device (using another fido2 device to authenticate).
Compromise of FIDO2 devices is particularly interesting though. Specialized hardware like a yubikey rather than software based fido2 might help here, but that still leaves theft as a wide open vector. If theft is a risk for your use case, https://www.yubico.com/blog/getting-a-biometric-security-key... could be an interesting solution or using secure hardware on your phone behind a lockscreen. Also having a password (in addition to webauthn) might be good enough for you to slow down an attacker enough for you to disable your compromised device (using another fido2 device to authenticate).
"Passwords must be shared to work"
Generally speaking, you are "sharing" your password with an entity that you wish to share or at least access other resources too. There has to be a degree of trust relationship of some sort, regardless of what scheme you choose for authentication.
Getting the relationship right is the really complicated, or at least, the most important part of the equation, the rest is tiddlywinks! There is no point getting all steamed up over one authentication scheme or another unless the whole transaction is considered end to end.
Passwords can work and work well, in certain circumstances, as do all the other authentication methods. They all have success and failure modes of one sort or another.
"The realm of free software is home to surveillance by the network" - what does that actually mean?
Generally speaking, you are "sharing" your password with an entity that you wish to share or at least access other resources too. There has to be a degree of trust relationship of some sort, regardless of what scheme you choose for authentication.
Getting the relationship right is the really complicated, or at least, the most important part of the equation, the rest is tiddlywinks! There is no point getting all steamed up over one authentication scheme or another unless the whole transaction is considered end to end.
Passwords can work and work well, in certain circumstances, as do all the other authentication methods. They all have success and failure modes of one sort or another.
"The realm of free software is home to surveillance by the network" - what does that actually mean?
>"The realm of free software is home to surveillance by the network" - what does that actually mean?
Easy! Let's look at the words one by one:
* "The network", implied being the only one relevant to the reader, must therefore be The Internet
* "surveillance" means "observation", "looking at things", in the most general sense. How can The Internet look at things? The computers don't have agency; so we must revise "The Internet" to mean the people on the internet. Which is, for all intents and purposes, everyone.
* "Realm" means kingdom. In common usage, "Realm of..." means "everything relating to/comprising/surrounding ...". So "realm of free software" is just, well, free software and how it's used.
* Being "home to" something means that something is always there when we talk about concepts that lack agency, like the ability of people to look at things. "A is home to B" means that B is inherently a part of A.
So, putting it all together, we have:
>People knowing exactly what you make and how it's used is a part of making and using free software.
Or, to say it less clumsily:
>When you make free software, everyone can see how they're made and used
Simplifying further to:
>Anyone can see how free software is made and used
...which is, of course, the entire point. Duh.
Anyone; there you go, you're welcome!
PS: speech like that is exactly what Orwell wrote against back in the day[1]. You will enjoy reading it.
[1]https://www.orwellfoundation.com/the-orwell-foundation/orwel...
Easy! Let's look at the words one by one:
* "The network", implied being the only one relevant to the reader, must therefore be The Internet
* "surveillance" means "observation", "looking at things", in the most general sense. How can The Internet look at things? The computers don't have agency; so we must revise "The Internet" to mean the people on the internet. Which is, for all intents and purposes, everyone.
* "Realm" means kingdom. In common usage, "Realm of..." means "everything relating to/comprising/surrounding ...". So "realm of free software" is just, well, free software and how it's used.
* Being "home to" something means that something is always there when we talk about concepts that lack agency, like the ability of people to look at things. "A is home to B" means that B is inherently a part of A.
So, putting it all together, we have:
>People knowing exactly what you make and how it's used is a part of making and using free software.
Or, to say it less clumsily:
>When you make free software, everyone can see how they're made and used
Simplifying further to:
>Anyone can see how free software is made and used
...which is, of course, the entire point. Duh.
Anyone; there you go, you're welcome!
PS: speech like that is exactly what Orwell wrote against back in the day[1]. You will enjoy reading it.
[1]https://www.orwellfoundation.com/the-orwell-foundation/orwel...
Nope. I was making my point using a reflection of the language in the original blog post, where the author was talking about the free software "home" being free of surveillance. This was apparently different from the "home" of Apple and Facebook etc, where the user is buying into surveillance. My point is that it isn't, there are still vectors into installations made of free software.
Free software being out in the open makes analyzing it to find zero days easier, but also can be analyzed as a group. some companies, Google being a very notable case, are quite public about their efforts to evaluate and improve free software. So no, your distilled point is not the one I was trying to make.
Free software being out in the open makes analyzing it to find zero days easier, but also can be analyzed as a group. some companies, Google being a very notable case, are quite public about their efforts to evaluate and improve free software. So no, your distilled point is not the one I was trying to make.
> Passwords must be shared to work, therefore they can never truly be secret.
A disk encryption password doesn't need to be shared with anyone for it to work?
> WebAuthN is here now and has been ready for a couple years now.
At last, I can give my users all the inconvenience of 2FA, but without a second factor.
A disk encryption password doesn't need to be shared with anyone for it to work?
> WebAuthN is here now and has been ready for a couple years now.
At last, I can give my users all the inconvenience of 2FA, but without a second factor.
And how do you protect your secret keys, if passwords are fundamentally broken?
> o Passwords ARE fundamentally broken and they do not put you in control. Passwords must be shared to work, therefore they can never truly be secret.
There's one notable exception to that: the root of your trust (a device you decrypt) needs to be something you know, rather than something you have like a token. You can have private keys on that encrypted device, and you can have physical tokens as a second factor, but unless your root of trust is something in your head it can be taken from you.
There's one notable exception to that: the root of your trust (a device you decrypt) needs to be something you know, rather than something you have like a token. You can have private keys on that encrypted device, and you can have physical tokens as a second factor, but unless your root of trust is something in your head it can be taken from you.
>Passwords must be shared to work, therefore they can never truly be secret.
Password managers already fixed this. Your password is unique per website so it doesn't matter if the service knows it since they could already login as you anyway.
Password managers already fixed this. Your password is unique per website so it doesn't matter if the service knows it since they could already login as you anyway.
An adversary with network access (looking at you, corporate firewalls) can read your password as well, not only your computer and the service. If the site uses a CDN, then it's likely that the endpoint for the TLS connection is the edge node, not the service itself and that the connection is re-encrypted from the node to the service (or even on an unencrypted connection from there on).
An attacker may have breached the service and exfiltrate passwords. The service may have a config error and log plain-text passwords to an unsecured elasticsearch instance. The service provider may have bad security practices and store the password in plain text or using an insecure hashing scheme.
All of these problems go away if you use some sort of asymmetric authentication since the public part is by definition public.
An attacker may have breached the service and exfiltrate passwords. The service may have a config error and log plain-text passwords to an unsecured elasticsearch instance. The service provider may have bad security practices and store the password in plain text or using an insecure hashing scheme.
All of these problems go away if you use some sort of asymmetric authentication since the public part is by definition public.
> An adversary with network access (looking at you, corporate firewalls)
Well, if you use corporate device, you implicitly trust them, don't you? Some even sign put signature on a paper agreeing what the corporate body can do to you. Perhaps MITM your encrypted traffic with corporate installed root cert or whatever.
Otherwise if you use your own device, in the age of encrypted HTTP and other stuff - No, an adversary or corporate firewall cannot simply read your password.
Well, if you use corporate device, you implicitly trust them, don't you? Some even sign put signature on a paper agreeing what the corporate body can do to you. Perhaps MITM your encrypted traffic with corporate installed root cert or whatever.
Otherwise if you use your own device, in the age of encrypted HTTP and other stuff - No, an adversary or corporate firewall cannot simply read your password.
> Well, if you use corporate device, you implicitly trust them, don't you
Well, if you use microsoft, you implicitly trust them, don't you
Well, if you use <insert ISP>, you implicitly trust them, don't you
Well, if you use the internet, you implicitly trust them, don't you
Well, if you use microsoft, you implicitly trust them, don't you
Well, if you use <insert ISP>, you implicitly trust them, don't you
Well, if you use the internet, you implicitly trust them, don't you
Yes. If you don't trust microsoft and you use windows, than it doesn't matter what authentication system you use. If you used rsa keys for auth then you would still have a problem because microsoft could steal those keys.
> Well, if you use corporate device, you implicitly trust them, don't you? Some even sign put signature on a paper agreeing what the corporate body can do to you. Perhaps MITM your encrypted traffic with corporate installed root cert or whatever.
I may have to submit to the inspection of traffic whether I trust them or not and even if I trust them to have the best intentions, things go wrong and firewalls get hacked - and all of a sudden that nice capability is in the hands of an attacker. So even if I do trust them, I prefer mechanisms that work asymmetric.
I may have to submit to the inspection of traffic whether I trust them or not and even if I trust them to have the best intentions, things go wrong and firewalls get hacked - and all of a sudden that nice capability is in the hands of an attacker. So even if I do trust them, I prefer mechanisms that work asymmetric.
It is really interesting how long we have collectively tolerated, and continue to tolerate, many counterproductive password policies and password-related software problems and limitations that are explained in the linked talk and that affect many different software products, such as not being able to enter very long passwords in many applications, or having to change the password periodically. The xkcd quote mentioned in the talk sums it up nicely:
Through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess.
Relatedly, YouTube - where the talk is hosted - informs me that it will require 2-factor authentication starting on Nov. 1st for accessing YouTube Studio:
Action required: Turn on 2-Step Verification by November 1, 2021 or you will lose access to YouTube Studio
I wonder whether this would be necessary if better password practices were established, so that more secure passwords can be more readily used. The linked NIST guidelines are interesting, and include pertaining recommendations such as "Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.":
https://pages.nist.gov/800-63-3/sp800-63b.html
Through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess.
Relatedly, YouTube - where the talk is hosted - informs me that it will require 2-factor authentication starting on Nov. 1st for accessing YouTube Studio:
Action required: Turn on 2-Step Verification by November 1, 2021 or you will lose access to YouTube Studio
I wonder whether this would be necessary if better password practices were established, so that more secure passwords can be more readily used. The linked NIST guidelines are interesting, and include pertaining recommendations such as "Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.":
https://pages.nist.gov/800-63-3/sp800-63b.html
And sometimes their 2FA is SMS based. I don't use SMS. I don't use hardware phones in my workflow.
For Microsoft Teams I have no choice but to direct the call to a Twilio number and use a script to answer it and automatically hit #.
If you want 2FA, have support for hardware keys. Period.
For Microsoft Teams I have no choice but to direct the call to a Twilio number and use a script to answer it and automatically hit #.
If you want 2FA, have support for hardware keys. Period.
I recently bought a second Yubikey and wanted to go through my accounts to add it as a backup; you know, have one locked up so that if I ever break my primary, I'm not SOL.
Not only do only about half a dozen services I use actively support hardware security keys, even fewer support enrolling more than one. Worse, many only support SMS 2FA as the backup option, which I just can't abide.
Not only do only about half a dozen services I use actively support hardware security keys, even fewer support enrolling more than one. Worse, many only support SMS 2FA as the backup option, which I just can't abide.
Right, AWS is the biggest offender of this. Also, Coinbase, Kraken, and several others.
Seriously, deprecate SMS already. I deprecated it 10 years ago.
Seriously, deprecate SMS already. I deprecated it 10 years ago.
Sounds like your organisation has just limited the 2FA options in the auth settings.
Hardware keys are supported on Teams, along with software phones (that have a static number / extension) and a linked desktop/mobile app.
In fact FIDO2 hardware keys like Yubikey are part of what Microsoft refers to as ‘passwordless’ - see https://docs.microsoft.com/en-us/azure/active-directory/auth...
I assume you aren’t an admin on the account just because otherwise you could just disable 2FA properly rather than disabling it with a weird twillio workaround, although I have to give you credit, this is the most effort I have seen someone put in to subvert a security policy.
Hardware keys are supported on Teams, along with software phones (that have a static number / extension) and a linked desktop/mobile app.
In fact FIDO2 hardware keys like Yubikey are part of what Microsoft refers to as ‘passwordless’ - see https://docs.microsoft.com/en-us/azure/active-directory/auth...
I assume you aren’t an admin on the account just because otherwise you could just disable 2FA properly rather than disabling it with a weird twillio workaround, although I have to give you credit, this is the most effort I have seen someone put in to subvert a security policy.
Yeah I'm not an admin on the account and have no control over it.
An app doesn't work for me either, When I have a big rack-mounted immobile desktop that should if anything BE the 2FA device, if anything, not a 6-inch easily-stealable device.
An app doesn't work for me either, When I have a big rack-mounted immobile desktop that should if anything BE the 2FA device, if anything, not a 6-inch easily-stealable device.
Which gets you back to the problem OP has - trusting that device enough to make it a secure root of trust. Windows lets you do it, so do Android and iOS. But your admin, maybe not (or you're not on windows, which is more likely I guess).
FIDO2 keys still lack one of the main features of physical keys that make them great... you can have many copies. FIDO2 makes it impossible to copy a key, saying instead to always use multiple FIDO2 keys in all cases. This pretty much kills the idea for it to replace passwords as no one is going to set up 3+ keys for every site they login to. So it will only be of use to lock your password manager where registering multiple keys would be feasible.
You could use it to unlock a single oauth account that you could then use to login to other places. Problem with those systems is trading privacy for convenience.
You could use it to unlock a single oauth account that you could then use to login to other places. Problem with those systems is trading privacy for convenience.
It's a feature, not a bug, but in order for it to be a feature, every service should accept multiple FIDO2 keys. Many services get this utterly wrong, including AWS, while Google, Github, and Facebook notably have good implementations.
Why it's a feature: if you lose a key you can log in with another key and disable the lost key.
If you lose your house key you have no option but to change the lock, if you want to be safe from thieves.
Why it's a feature: if you lose a key you can log in with another key and disable the lost key.
If you lose your house key you have no option but to change the lock, if you want to be safe from thieves.
That feature will kill the standard outside of mandated (corporate/gov) use cases. There's no way I want to have to worry about registering 2-3 FIDO2 keys with every site I currently use passwords for. And there's no way I'd trust Google's (or any other company) OAuth to be my master login for every site.. assuming they all take OAuth and that Google accepted multiple FIDO2 keys.
IMO it's a mis-feature and will keep it from eliminating passwords. In fact I think it will only reinforce password use as the one good case for it is to lock your password manager.
IMO it's a mis-feature and will keep it from eliminating passwords. In fact I think it will only reinforce password use as the one good case for it is to lock your password manager.
> FIDO2 keys still lack one of the main features of physical keys that make them great... you can have many copies.
There is absolutely nothing stopping you from making a copiable FIDO key, and, in fact, most Bitcoin hardware wallets are just that, since they come with FIDO apps and you can copy the keys over to another hardware key. Or, you can write some Arduino firmware to make your own, copiable, FIDO2-compatible key.
There is absolutely nothing stopping you from making a copiable FIDO key, and, in fact, most Bitcoin hardware wallets are just that, since they come with FIDO apps and you can copy the keys over to another hardware key. Or, you can write some Arduino firmware to make your own, copiable, FIDO2-compatible key.
Do you know of any major players that support this? I'm only really aware of Yubico's offering and they don't have a model that allows copying.
Thanks for raising this point though. Lack of copy-ability is more an implementation issue than a problem with the standard.
Thanks for raising this point though. Lack of copy-ability is more an implementation issue than a problem with the standard.
Ledger wallets support U2F and are copiable. There's someone who's building an OSS hardware token that's also copiable (you can flash the same seed to as many hardware tokens as you want).
The protocol is open, though, so in theory you could semi-easily make your own FIDO2 key out of commodity hardware. The Solo 2 Hacker edition might also be copiable.
The protocol is open, though, so in theory you could semi-easily make your own FIDO2 key out of commodity hardware. The Solo 2 Hacker edition might also be copiable.
Not everyone has tolerated passwords. US President George W. Bush signed a Presidential Directive directing all parts of the US Government to make and implement plans for getting rid of passwords in August of 2004.
I’m looking on google for more information but struggling to formulate a query that yields good results. What were the results of this directive? Does the government no longer use passwords?
I left the IC just over a year ago and we were still using passwords. Although, the RSA tokens had just been rolled out. Most likely everyone on JWICS (if someone still in the space can correct me, please do) has now moved to a PIN+RSA token.
The government moves ever so slowly on some issues. I wouldn't be surprised if a directive on password policy signed in 2004 took 15 years to implement.
The government moves ever so slowly on some issues. I wouldn't be surprised if a directive on password policy signed in 2004 took 15 years to implement.
IC users on JWICS use IC ITE PKI. You get issued a client cert and key when you get an account, and that is used to authenticate you to all web-based services. Additionally, it links directly to your clearance, so it automatically redacts content based on the portion label, meaning you can do something like load Intellipedia and it will not show you parts of pages containing information you have inadequate clearance to see, but still show you everything else. 2FA is implemented by requiring you to unlock your private key with a 8-digit pin.
It is light years ahead of the public world wide web. But, of course, the problem is a lot easier to solve when you have a single source of identity for every user and every user only has a single identity. Something like this is impossible if you want any level of anonymity, but users of government systems have no expectation of anonymity.
It is light years ahead of the public world wide web. But, of course, the problem is a lot easier to solve when you have a single source of identity for every user and every user only has a single identity. Something like this is impossible if you want any level of anonymity, but users of government systems have no expectation of anonymity.
My experience was with DOD. They made major strides by 2010 to use smart cards (CAC) for access control to all the major systems. Some systems still had passwords, but everything new was supposed to use CAC and everything old was being migrated to support CAC in addition to passwords, ideally dropping passwords (not always possible due to how some things were accessed).
>I’m looking on google for more information but struggling to formulate a query
I'm guessing Homeland Security Presidential Directive 12 (HSPD-12) https://www.doi.gov/hspd12/directives
"'Secure and reliable forms of identification' for purposes of this directive means identification that (a) is issued based on sound criteria for verifying an individual employee's identity; (b) is strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation; (c) can be rapidly authenticated electronically; and (d) is issued only by providers whose reliability has been established by an official accreditation process. The Standard will include graduated criteria, from least secure to most secure, to ensure flexibility in selecting the appropriate level of security for each application. The Standard shall not apply to identification associated with national security systems as defined by 44 U.S.C. 3542(b)(2)."
I'm guessing Homeland Security Presidential Directive 12 (HSPD-12) https://www.doi.gov/hspd12/directives
"'Secure and reliable forms of identification' for purposes of this directive means identification that (a) is issued based on sound criteria for verifying an individual employee's identity; (b) is strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation; (c) can be rapidly authenticated electronically; and (d) is issued only by providers whose reliability has been established by an official accreditation process. The Standard will include graduated criteria, from least secure to most secure, to ensure flexibility in selecting the appropriate level of security for each application. The Standard shall not apply to identification associated with national security systems as defined by 44 U.S.C. 3542(b)(2)."
Yes, I was referring to HSPD-12 of 27-AUG-2004.
As a sibling comment pointed out this was a reference Homeland Security Presidential Directive 12 (HSPD-12). The results were that the vast majority of systems did not use passwords. You can check out the status over time by googling "HSPD-12 Status Report" (no quotes) and check for the various agencies that fall within the US Executive branch.
The DOD led the charge with the DOD Common Access Card (CAC), which became standardized (more or less; there was the GSC-IS which did specify the CAC) as the PIV in NIST SP 800-73, and this is what practically everyone uses today.
The PIV is just a smartcard, like your favorite chip-and-pin card (ISO 7816). Which is just a tiny computer you send datagrams/packets (APDUs) to request that it do work, and it sends you back responses. It has your private keys on it, as well as some certificates for you to present and that's pretty much it.
The vast majority of deployments people use this in combination with some other tools. For example with PKINIT with Kerberos, and then most authentication/authorization occurs using the Ticket Granting Ticket (TGT) you get with from Kerberos. Direct authentication using TLS Client Certificate Authentication is also used in some cases (since it requires less infrastructure). SAML IdPs are also used, usually in conjunction with Kerberos or TLS Client Certificate Authentication.
The DOD led the charge with the DOD Common Access Card (CAC), which became standardized (more or less; there was the GSC-IS which did specify the CAC) as the PIV in NIST SP 800-73, and this is what practically everyone uses today.
The PIV is just a smartcard, like your favorite chip-and-pin card (ISO 7816). Which is just a tiny computer you send datagrams/packets (APDUs) to request that it do work, and it sends you back responses. It has your private keys on it, as well as some certificates for you to present and that's pretty much it.
The vast majority of deployments people use this in combination with some other tools. For example with PKINIT with Kerberos, and then most authentication/authorization occurs using the Ticket Granting Ticket (TGT) you get with from Kerberos. Direct authentication using TLS Client Certificate Authentication is also used in some cases (since it requires less infrastructure). SAML IdPs are also used, usually in conjunction with Kerberos or TLS Client Certificate Authentication.
This is a major change from the original NIST guidance that MS & dog previously followed. It turns out the author of that guidance admitted not so long ago that it was basically rubbish: just like the half dozen or more boxes that security managers have been mindlessly checking since 2004 (to be sure many of those misguided policies had become canon long before being enshrined in NIST's standards). It was the snakeoil press that made millions (billions?) for the producers and actors engaged in over a decade of security theater. The independent genius and intellectual courage of XKCD's author can only be fully appreciated against that background. https://www.engadget.com/2017-08-08-nist-new-password-guidel...
2FA is necessary because users still consistently fall for phishing attacks. Password policies wouldn’t effect that.
There’s also the password reuse problem, though better policies might discourage reuse, it’ll still happen.
There’s also the password reuse problem, though better policies might discourage reuse, it’ll still happen.
[deleted]
Who needs passwords when your identity is owned by a corporation?
Use your^W the newest rented iDevice in your vicinity to confirm your identity. Make sure to replace the device regularly and have an active subscription to our movies, music, spying, and more services so that we can fulfill your banking login request today. It's important that you eat so that you may work and consume more.
We'll charge the customary 55% fee to everyone you interact with that isn't in our device platform bubble. Make sure not to log in with their account system or you may find your identity reputation score lowered and your chat bubbles rendered in poop brown to your peer group. How disgraceful.
Remember to buy our official chargers. Here are some ads from third party sponsors. Thank you.
Use your^W the newest rented iDevice in your vicinity to confirm your identity. Make sure to replace the device regularly and have an active subscription to our movies, music, spying, and more services so that we can fulfill your banking login request today. It's important that you eat so that you may work and consume more.
We'll charge the customary 55% fee to everyone you interact with that isn't in our device platform bubble. Make sure not to log in with their account system or you may find your identity reputation score lowered and your chat bubbles rendered in poop brown to your peer group. How disgraceful.
Remember to buy our official chargers. Here are some ads from third party sponsors. Thank you.
Exactly. The authoritarian "security" industry is largely to blame for helping to build this dystopia of corporate control.
More than three decades of bugs, crashes, worms, virused, trojans, hackers, scammers, social engineering, ransomware, idiot users and the occasional battery fire. I'd secure my device as well.
A forbidden thought.
"Remember to buy our official chargers. Here are some ads from third party sponsors."
Holy hell this hit hard.
Holy hell this hit hard.
"It's as simple and painless as letting us record the unique biometric markers in your right hand or forehead, and then you're on your way to enjoying the global economic system that you're required to use.
Just make sure you agree to the 13,000 word self-updating terms of service, and don't use our devices to express any opinions that go against the set of socially acceptable beliefs that our company expects all its employees and users to hold."
Just make sure you agree to the 13,000 word self-updating terms of service, and don't use our devices to express any opinions that go against the set of socially acceptable beliefs that our company expects all its employees and users to hold."
mastrsushi(2)
This was a really weird article that reminded me of circa 1999 Slashdot.
It’s easy to throw heat at Microsoft. But… 2021 crypto and security is different than 1991. The standards this stuff was built around were for an era where local dictionary attacks were common and a serious threat. They still are in many scenarios.
If you’re going to throw shit at Microsoft, attack their head in the sand approach to NTLM, their implicit deprecation and failure to develop AD further and prioritization of monetization over baseline product needs.
It’s easy to throw heat at Microsoft. But… 2021 crypto and security is different than 1991. The standards this stuff was built around were for an era where local dictionary attacks were common and a serious threat. They still are in many scenarios.
If you’re going to throw shit at Microsoft, attack their head in the sand approach to NTLM, their implicit deprecation and failure to develop AD further and prioritization of monetization over baseline product needs.
If my understanding is right to this day on prem AD does not salt its passwords and MS is not doing anything to address that weakness. That should make everyone tear out their on prem AD.
AD exists as it does today because they were able to meet the USGs definition of a distinct crypto module in the 90s, and it’s too popular to break by policy.
AES keys are salted. Moreover, if you use public key authentication (e.g. smartcard, FIDO) it's not a requirement that any keys are provisioned on the user. I'm not sure if you can disable the generation of the NTLM key when using passwords, though (and it's true, that is unsalted).
Active directory is on the back-burner because it just doesn't have the same growth potential as other products. Everyone who wants to use AD is already using it, and the market size is limited by the number of employees at businesses.
If a business grows their customer base by 100x, they don't grow headcount at the same rate. But their resource consumption of cloud managed services will increase more proportionally to the customer base.
If a business grows their customer base by 100x, they don't grow headcount at the same rate. But their resource consumption of cloud managed services will increase more proportionally to the customer base.
If you sell a customer an application, say AD and ADFS, and hobble it so that you sell them the same services again (Azure P2), that is indeed very profitable.
Most of the employee costs are CALs, so they are increasing the price significantly if you need security mechanisms that AD cannot provide.
The products for customer use are different and don’t really align with the AD bread and butter story, which has always been employees.
Most of the employee costs are CALs, so they are increasing the price significantly if you need security mechanisms that AD cannot provide.
The products for customer use are different and don’t really align with the AD bread and butter story, which has always been employees.
Excellent article - "passwordless" is Microsoft's (and BigTech's) attempts to take away more control from us, similar to Apple's "delayed" attempt to violate our rights by scanning our device for "illegal" content (begining with CSAM).
I want my passwords back. Windows hello doesn’t know who the hell I am until after lunch.
It knew who you were before lunch?
> This baseline 12-character minimum means folks won’t be tempted to reuse their insecure (but technically complex!) 8-character password mullets from other sites.
Instead they'll re-use their insecure (but technically complex!) 12-character passwords from other sites. So much better. /s
Face it: passwords suck. They're far too easy to misuse (re-using compromised[1] passwords from other services) and far too difficult to use correctly (long, random, unique passwords for every service). At this point I'm inclined to support just about any alternative that isn't even more horribly flawed.
Ideally yeah, an open source solution would be preferred. WebAuthn nearly has this solved for the web; we just need a cross-platform authenticator for it. For local device logins (such as to Windows PCs) neither WebAuthn nor password managers work particularly well, so I'm glad Microsoft is exploring alternatives there.
[1]: https://haveibeenpwned.com/Passwords
Instead they'll re-use their insecure (but technically complex!) 12-character passwords from other sites. So much better. /s
Face it: passwords suck. They're far too easy to misuse (re-using compromised[1] passwords from other services) and far too difficult to use correctly (long, random, unique passwords for every service). At this point I'm inclined to support just about any alternative that isn't even more horribly flawed.
Ideally yeah, an open source solution would be preferred. WebAuthn nearly has this solved for the web; we just need a cross-platform authenticator for it. For local device logins (such as to Windows PCs) neither WebAuthn nor password managers work particularly well, so I'm glad Microsoft is exploring alternatives there.
[1]: https://haveibeenpwned.com/Passwords
> Instead they'll re-use their insecure (but technically complex!) 12-character passwords from other sites. So much better. /s
Yeah. In fact, I'd wager that longer password lengths make reuse even more common if people aren't using password managers.
Yeah. In fact, I'd wager that longer password lengths make reuse even more common if people aren't using password managers.
> long, random, unique passwords for every service
Using a password manager is not that difficult. Then you really have to worry about one password, the one to unlock the password manager, and don't even have to think about the others. There are plenty of open source password manager to choose from.
Using a password manager is not that difficult. Then you really have to worry about one password, the one to unlock the password manager, and don't even have to think about the others. There are plenty of open source password manager to choose from.
Well, the master password... and all the passwords you can't store in the pass manager. Like the Windows log-in password, the Bitlocker password, your cell phone PIN, (your bank card PIN)...
You can absolutely still store those in your password manager...
But you can't retrieve them when you need to use them, so why would you?
That regardless you have to remember anyway. But instead of having to remember 100 password, you have to remember only 5.
The trick is having a password manager and associated password database synchronised across your linux/windows/android/iOS/MacOS devices.
Password managers help mitigate the second problem (passwords being hard to use correctly) but do absolutely nothing for the first one (passwords being easy for users to shoot themselves in the foot with by using them incorrectly). Even the most user-friendly, well-designed password manager is still less convenient than just re-using the same password everywhere.
> "Knowing that all Windows 11 computers will have a TPM allows them to enforce that all Windows 11 hardware only runs software Microsoft has signed"
This seems… wrong? Or, at least, one does not directly follow from the other. You don't need a strong hardware root of trust to enforce signing requirements - if Microsoft wanted that, they could do so without requiring a TPM at all.
This seems… wrong? Or, at least, one does not directly follow from the other. You don't need a strong hardware root of trust to enforce signing requirements - if Microsoft wanted that, they could do so without requiring a TPM at all.
There's a certain kind of tinfoil-hat people who predict that Microsoft is about to restrict what software they can run on their computers. There were similar conspiracy theories when Windows 8 launched - some kind of secure boot scheme.
Never mind that nothing of the sort happened and you can still run whatever you want on your PC, both with and without Windows. Meanwhile Apple has all kinds of anti-competitive restrictions but this is fine.
Never mind that nothing of the sort happened and you can still run whatever you want on your PC, both with and without Windows. Meanwhile Apple has all kinds of anti-competitive restrictions but this is fine.
> Never mind that nothing of the sort happened and you can still run whatever you want on your PC
To be fair, that was largely because of significant public pushback on early versions of the Microsoft requirements (which didn't require that it be possible to disable secure boot) and a lot of negotiation with Microsoft to ensure that third party operating systems would be able to get signatures.
(Source: one of the people who designed and implemented Shim and ensured that Microsoft would be willing to sign it)
To be fair, that was largely because of significant public pushback on early versions of the Microsoft requirements (which didn't require that it be possible to disable secure boot) and a lot of negotiation with Microsoft to ensure that third party operating systems would be able to get signatures.
(Source: one of the people who designed and implemented Shim and ensured that Microsoft would be willing to sign it)
Even if you trust Microsoft not to abuse its "secure (against the user) boot" scheme, despite the evidence[0], you should realise how eager governments are to remove apps from app stores and how quickly they would take advantage of a technology that allows them to limit desktops and laptops to running only "approved" applications too.
People rightly foresaw the potential for scope-creep in Apple's latest device-side file scanning "feature", and we should be similarly cautious for any similar feature that makes it hard for Microsoft to oppose enforcing a government-maintained blacklist or whitelist of installable software.
[0] https://www.computerworld.com/article/2542952/aussies-rage-a...
People rightly foresaw the potential for scope-creep in Apple's latest device-side file scanning "feature", and we should be similarly cautious for any similar feature that makes it hard for Microsoft to oppose enforcing a government-maintained blacklist or whitelist of installable software.
[0] https://www.computerworld.com/article/2542952/aussies-rage-a...
There's a certain kind of tinfoil-hat people who predict that Microsoft is about to restrict what software they can run on their computers.
Try writing a device driver for recent versions of Windows and getting it to work without signing it...
Stallman has been and will continue to be right on this point.
Try writing a device driver for recent versions of Windows and getting it to work without signing it...
Stallman has been and will continue to be right on this point.
> Try writing a device driver for recent versions of Windows and getting it to work without signing it...
Disable secure boot and disable integrity checks with bcdedit?
Disable secure boot and disable integrity checks with bcdedit?
This article doesn’t do a great job of explaining what the supposed password-less future is. Based on Microsoft’s article[1] it seems like it will fully be reliant on your mobile phone and the authenticator app that you will have to install on it.
What happens when someone gets access to your phone? What happens when you lose it? Does the app on the phone have the same protections under the law as passwords[2]. Is this just 2fa without any passwords at all involved?
Just a few questions and doubts I could come up with in a small timespan.
[1] http://microsoft.com/security/blog/2021/09/15/the-passwordle...
[2] https://time.com/3558936/fingerprint-password-fifth-amendmen...
What happens when someone gets access to your phone? What happens when you lose it? Does the app on the phone have the same protections under the law as passwords[2]. Is this just 2fa without any passwords at all involved?
Just a few questions and doubts I could come up with in a small timespan.
[1] http://microsoft.com/security/blog/2021/09/15/the-passwordle...
[2] https://time.com/3558936/fingerprint-password-fifth-amendmen...
The app can be configured to require a PIN/fingerprint to authenticate you. The 2 factors become control of the phone and your fingerprint.
If you have a fingerprint or can hack it, it basically will let you into the phone and into the auth app.
Yep. But no-one ever leaves their fingerprints on their phone, so this is 100% safe. /s
I always thought fingerprint readers were weaker security than passwords. I mean, fingerprints can be legally obtained and it is much easier to put a hacked fingerprint reader (that always gives your real fingerprint to your device) than breaking strong encryption.
A good fingerprint reader is cryptographically bound to the fingerprints stored on the device through e.g. a private key available only to the fingerprint chip. Replacing the fingerprint reader would therefore require the user to add their fingerprints to the system once again.
Is that how it is done these days? Also this will not prevent a physical identical fingerprint model attack: https://www.darkreading.com/endpoint/researchers-fool-biomet...
I’ve seen the EFF mention that the police is working technologies that will allow them do this amass. Also see the article OP (me) mentioned in link 2. Biometric passwords have less protection under the law in the US.
> Is that how it is done these days?
Well, I don't know the exact specifics, but that's how I would implement security for biometrics input devices. Apart from that, I seem to recall that Apple does something with validating various sensors and rejecting "unknown" sensors (although that might be based on sensor make/model/SN and not necessarily cryptographic)
> Also this will not prevent a physical identical fingerprint model attack
Correct, but no fingerprint reader that is only a fingerprint reader will prevent such an attack: No lock is made to be unopenable by (a copy of) the key to that lock. If your fingerprint is the key, a good enough physical copy of the fingerprint will open the locked device.
Well, I don't know the exact specifics, but that's how I would implement security for biometrics input devices. Apart from that, I seem to recall that Apple does something with validating various sensors and rejecting "unknown" sensors (although that might be based on sensor make/model/SN and not necessarily cryptographic)
> Also this will not prevent a physical identical fingerprint model attack
Correct, but no fingerprint reader that is only a fingerprint reader will prevent such an attack: No lock is made to be unopenable by (a copy of) the key to that lock. If your fingerprint is the key, a good enough physical copy of the fingerprint will open the locked device.
Also, whatever is used as password must satisfy at least these 2 requirements:
- It should be known only by you and
- it should be easy to change in case it is compromised.
Why does this idea keep being perpetuated? Biometric auth is not "a picture of my fingerprint is the password."
Imagine a human guard tasked with authenticating people with a database of fingerprints. Someone comes up says that they're John Jameson, the guard takes their hand and makes an impression with some ink and paper and then compares it to impression they have on file for Mr. Jameson. Could you hack this system by lifting John's prints? Nope!
Why? Because the real trick to biometric auth isn't that your fingerprint is secret, it's that it's somewhere between difficult to impossible (depending on the metric) to produce a living breathing human with the same biometric readings as you. The strength of a biometric auth system is determined by how well it can determine that the reading it's taking is coming from a human. You don't ever have to rotate your fingerprint or your face because it doesn't need to be secret for these systems to work.
Imagine a human guard tasked with authenticating people with a database of fingerprints. Someone comes up says that they're John Jameson, the guard takes their hand and makes an impression with some ink and paper and then compares it to impression they have on file for Mr. Jameson. Could you hack this system by lifting John's prints? Nope!
Why? Because the real trick to biometric auth isn't that your fingerprint is secret, it's that it's somewhere between difficult to impossible (depending on the metric) to produce a living breathing human with the same biometric readings as you. The strength of a biometric auth system is determined by how well it can determine that the reading it's taking is coming from a human. You don't ever have to rotate your fingerprint or your face because it doesn't need to be secret for these systems to work.
As I said: fingerprints are good identifiers, not good passwords.
Fingerprint is fine, maybe, sort of, for situations where your threat model doesn't involve someone compelling you to put your finger on the device. But PINs are just a step backward and I'm not sure why we should get on-board with replacing one form of knowledge auth with a weaker form of knowledge auth.
What happens if you don’t own a smartphone? You’re disenfranchised from society.
My grandmother is 81, makes about $23k in pension and SS income. Why does she need to invest in a device the she cannot use?
My grandmother is 81, makes about $23k in pension and SS income. Why does she need to invest in a device the she cannot use?
Most 2FA services like Google also allow hardware keys like yubikeys. I don't see support for these disappearing anytime soon since they are a requirement for many certifications (like Fedramp).
Google even lets you enroll more than one key, in case you lose your primary! AWS doesn't, but at least they accept Yubikey's budget U2F keys. Can't recall if MSFT does yet.
I'm a HN denizen, have a PhD, can code in a multitude of languages, etc etc etc. I don't own a smartphone and it gets less and less appealing every year.
I will fight 'smart passports' tooth and nail to my grave. It's insanity to imagine that if I'm not tethered to a computer chip I'm not a valid member of society. And I say that as someone who loves computer chips. There are complaints on HN every day about the impacts of invasive technologies and then a thread like this comes by where the "solution" is to assume someones identity is their smartphone. Yikes.
Last year I was denied access to a concert because they only gave tickets by a smartphone app and the woman looked at me like I was insane when I explained how that wasn't possible for me. I'm an otherwise normal member of society, a healthy and fit 32 year old male. But apparently I'm an unacceptable outsider if I don't want to carry an always on cell-phone modem directly integrated with one of the most powerful CPUs in history with access to my GPS location that was made in a sweat shop in China by a company with no direct stake in my personal well being. She literally said 'but you look normal' when I explained that I didn't have a smartphone.
I will fight 'smart passports' tooth and nail to my grave. It's insanity to imagine that if I'm not tethered to a computer chip I'm not a valid member of society. And I say that as someone who loves computer chips. There are complaints on HN every day about the impacts of invasive technologies and then a thread like this comes by where the "solution" is to assume someones identity is their smartphone. Yikes.
Last year I was denied access to a concert because they only gave tickets by a smartphone app and the woman looked at me like I was insane when I explained how that wasn't possible for me. I'm an otherwise normal member of society, a healthy and fit 32 year old male. But apparently I'm an unacceptable outsider if I don't want to carry an always on cell-phone modem directly integrated with one of the most powerful CPUs in history with access to my GPS location that was made in a sweat shop in China by a company with no direct stake in my personal well being. She literally said 'but you look normal' when I explained that I didn't have a smartphone.
> I don't want to carry an always on cell-phone modem directly integrated with one of the most powerful CPUs in history with access to my GPS location that was made in a sweat shop in China by a company with no direct stake in my personal well being.
If this is your main concern with the smartphones, and you love computer chips, you may be interested in the GNU/Linux phone with hardware kill switches produced by the company that wrote the article: https://puri.sm/products/librem-5.
If this is your main concern with the smartphones, and you love computer chips, you may be interested in the GNU/Linux phone with hardware kill switches produced by the company that wrote the article: https://puri.sm/products/librem-5.
It is comments like these that make me want to form a separate nation. I don't want what everyone is selling, but soon the option not to buy will be taken away.
[deleted]
Similar story here. Went from android to google-free android to nothing. But I had to go back and buy a shitty 50$ smartphone because my bank would no longer allow me to invest without their 2FA app. I called them to explain I didn't have a smartphone and didn't want one and the answer was basically "tough shit, you lunatic".
I'm in early twenties and I too don't use them, but fortunely I haven't been denied on anything yet, but I'm still worried that some bullshit will force me to get one.
> It's insanity to imagine that if I'm not tethered to a computer chip I'm not a valid member of society.
Is it? What's special about computer chips vs. id cards?
Is it? What's special about computer chips vs. id cards?
I'll take this as a sincere question.
An ID card is something I keep in my pocket when I need it and it serves one purpose and is close-to-free in financial and time costs. A computer chip is expensive, turing complete, and has enough data about me to do just about anything you might imagine.
An ID card is something I keep in my pocket when I need it and it serves one purpose and is close-to-free in financial and time costs. A computer chip is expensive, turing complete, and has enough data about me to do just about anything you might imagine.
To nitpick, a low end phone is plausibly less expensive and easier to acquire than a license with a processing fee and physical dmv presence requirement. It's also not obvious to me why turing complete is a bad thing
Would you object to the requirement if you were running on a phone that had open hardware and open software and you felt reasonably sure it wasn't doing anything you didn't expect?
Would you object to the requirement if you were running on a phone that had open hardware and open software and you felt reasonably sure it wasn't doing anything you didn't expect?
Ironically, a major reason not to use a smart phone is that they become insecure so quickly. Buy any smart phone, wait a few years, and it will no longer receive security updates and be 100% hackable by any script kid.
You are so eloquent in explaining this!
Good on you. That is great.
> I will fight 'smart passports' tooth and nail to my grave
I don't know what your definition of a "smart passport" is, but the ones we have in the EU are pretty awesome. NFC chip on them that can be scanned to provide the biometric data - use cases are automatic identity checks at airports with passport+smart camera that compares, and the same via a government provided app where you take a video of your face, scan the chip, and the app compares them. Both are great, secure ( much more so that sending a scanned copy of your passport/ID card), practical, and can and are done with privacy in mind ( as much as privacy is possible for the airport scenario).
I don't understand people like you. Making people's lives easier is one of the main points of tech. All such advances on that particular level should be done with old school backups for people who can't use the tech (old, disabled, etc.) but those should be the exceptions. If almost everyone can use a system which is more secure, takes less time, and requires less money/time to run, why not? Why not make it the default? Why not make life easier for 90%+ of the adult population?
I don't know what your definition of a "smart passport" is, but the ones we have in the EU are pretty awesome. NFC chip on them that can be scanned to provide the biometric data - use cases are automatic identity checks at airports with passport+smart camera that compares, and the same via a government provided app where you take a video of your face, scan the chip, and the app compares them. Both are great, secure ( much more so that sending a scanned copy of your passport/ID card), practical, and can and are done with privacy in mind ( as much as privacy is possible for the airport scenario).
I don't understand people like you. Making people's lives easier is one of the main points of tech. All such advances on that particular level should be done with old school backups for people who can't use the tech (old, disabled, etc.) but those should be the exceptions. If almost everyone can use a system which is more secure, takes less time, and requires less money/time to run, why not? Why not make it the default? Why not make life easier for 90%+ of the adult population?
The underlying uneasiness of people fighting this kind of technology is that it is technology that gives more power to a government, and that power can be then used against you if the government gets corrupted one way or another : if a wannabe dictators gets to power and destroy democratic power balance, or fascists gets to power, etc...
A common rebuttal to this is that democracy is strong enough to withstand this, and that if it happens, people will rebel. Another fear is then that the government gets enough power from the technological advance that the people rebelling will become not strong enough, or that the government will have so much influence in people's life that they will be able to squash rebellion before it even takes form.
A common rebuttal to this is that democracy is strong enough to withstand this, and that if it happens, people will rebel. Another fear is then that the government gets enough power from the technological advance that the people rebelling will become not strong enough, or that the government will have so much influence in people's life that they will be able to squash rebellion before it even takes form.
> The underlying uneasiness of people fighting this kind of technology is that it is technology that gives more power to a government, and that power can be then used against you if the government gets corrupted one way or another : if a wannabe dictators gets to power and destroy democratic power balance, or fascists gets to power, etc...
If that happens, everyone is screwed anyways, what difference does it make if your passport has a machine readable chip?! All governments in developed countries know all of their citizens. Making that knowledge and verification more easily usable in specific scenarios ( like verifying your identity online for government services or at airports) doesn't change anything with regards to what the government knows or has. In both the scenarios, even with paper forms/manual checks, they still know who you are (when were you born, how much taxes you pay, parents, address, etc.) and what you did in that precise moment ( passed through airport or filled taxes online).
IMHO refusing technological progress that makes lives easier for almost everyone on unfounded fears is wrong. Discussions should be had about how to do that progress in the best/most secure way possible, but refusing it outright? It's just being a luddite for the sake of it.
If that happens, everyone is screwed anyways, what difference does it make if your passport has a machine readable chip?! All governments in developed countries know all of their citizens. Making that knowledge and verification more easily usable in specific scenarios ( like verifying your identity online for government services or at airports) doesn't change anything with regards to what the government knows or has. In both the scenarios, even with paper forms/manual checks, they still know who you are (when were you born, how much taxes you pay, parents, address, etc.) and what you did in that precise moment ( passed through airport or filled taxes online).
IMHO refusing technological progress that makes lives easier for almost everyone on unfounded fears is wrong. Discussions should be had about how to do that progress in the best/most secure way possible, but refusing it outright? It's just being a luddite for the sake of it.
> If that happens, everyone is screwed anyways, what difference does it make if your passport has a machine readable chip?!
The difference it makes is that with such tech, I wouldn't have been born because my grand-parents would have been executed and my mother sent to a KZ, for they couldn't have easily forged various more or less believable identity papers and they couldn't have benefited of hard to cross-check databases.
But what is it, in regard of the convenience of going 2 minutes faster through customs check during the yearly holiday across the ocean, after all?
The difference it makes is that with such tech, I wouldn't have been born because my grand-parents would have been executed and my mother sent to a KZ, for they couldn't have easily forged various more or less believable identity papers and they couldn't have benefited of hard to cross-check databases.
But what is it, in regard of the convenience of going 2 minutes faster through customs check during the yearly holiday across the ocean, after all?
And going by that logic, nothing would ever be done. We don't live in Nazi Germany, and it's our responsibility to not allow the countries we live in to use it for inspiration, not to avoid anything that could have been abused under that regime. Going by your logic *which btw would be impossible to impose today, however hard to cross-check databases you make, a tyrannical government would find a way to cross-check them), we shouldn't have banking, debit/credit cards, mobile phones, the Internet, digital services, online ordering, etc.
> But what is it, in regard of the convenience of going 2 minutes faster through customs check during the yearly holiday across the ocean, after all?
It's not 2 minutes, it's the whole flow - having seen it implemented in some airports, the automatic queue is much faster than the one with physical border police checking your ID and looking at you.
And you're conveniently ignoring the other main use case, verifying your identity securely to be able to do bureaucratic stuff from the comfort and convenience of your home, without having to take time and queue up in an office somewhere.
> But what is it, in regard of the convenience of going 2 minutes faster through customs check during the yearly holiday across the ocean, after all?
It's not 2 minutes, it's the whole flow - having seen it implemented in some airports, the automatic queue is much faster than the one with physical border police checking your ID and looking at you.
And you're conveniently ignoring the other main use case, verifying your identity securely to be able to do bureaucratic stuff from the comfort and convenience of your home, without having to take time and queue up in an office somewhere.
> If that happens, everyone is screwed anyways, what difference does it make if your passport has a machine readable chip?! All governments in developed countries know all of their citizens.
In case it happens, the lack of always-on, uncontrollable surveillance can help you to become a dissident and fight the corruption. Otherwise you will get in jail or killed immediately if you try.
In case it happens, the lack of always-on, uncontrollable surveillance can help you to become a dissident and fight the corruption. Otherwise you will get in jail or killed immediately if you try.
A passport with a chip in it isn't
`the lack of always-on, uncontrollable surveillance`
And even if it somehow did, you leave the device at home while you go out on your dissidence business.
Again, this is hugely overblown.
`the lack of always-on, uncontrollable surveillance`
And even if it somehow did, you leave the device at home while you go out on your dissidence business.
Again, this is hugely overblown.
> you leave the device at home while you go out on your dissidence business
This is not so simple at all. Mobile phones are required everywhere now, from reading a menu in a cafe to entering a building with QR-codes (against corona, of course). I am not even speaking about importance of communication with other people.
Also, no government turns into a tyranny overnight. It happens slowly and most people will not be aware of it until late, including dissidents.
This is not so simple at all. Mobile phones are required everywhere now, from reading a menu in a cafe to entering a building with QR-codes (against corona, of course). I am not even speaking about importance of communication with other people.
Also, no government turns into a tyranny overnight. It happens slowly and most people will not be aware of it until late, including dissidents.
Re the QR code, can't you just print it out on a paper?
We passed that point decades ago. It's as insanely stupid as the thought that right to bear arms could stop government.
The grandparent comment is misleading. To quote the Microsoft post (and I checked, it didn't change in the last few hours):
> Beginning today, you can now completely remove the password from your Microsoft account. Use the Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email
So if your grandmother has a Microsoft account and can't use a phone, she'll have the alternatives of using face or fingerprint recognition, using a hardware key, … or just continuing to use a password, since this whole thing is optional.
Not that there isn't a real concern that society is becoming harder to access without a smartphone, in general. But it's pretty much unrelated to what Microsoft is doing.
> Beginning today, you can now completely remove the password from your Microsoft account. Use the Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email
So if your grandmother has a Microsoft account and can't use a phone, she'll have the alternatives of using face or fingerprint recognition, using a hardware key, … or just continuing to use a password, since this whole thing is optional.
Not that there isn't a real concern that society is becoming harder to access without a smartphone, in general. But it's pretty much unrelated to what Microsoft is doing.
It's optional for now - anyone who hangs around here must surely know how tech companies are prone to breaking things that work in the name of progress. Forced Windows updates, anyone?
If this idea gains traction then Microsoft will roll over the objections of those who can't/won't use it, and tough luck.
If this idea gains traction then Microsoft will roll over the objections of those who can't/won't use it, and tough luck.
Yes, you should always have a backup way of authenticating, not just your phone. One approach is to get a Yubikey, or maybe two.
Microsoft also supports hardware security keys.
Agreed. That’s why I’d still prefer 2FA rather than make it just this one factor.
There are attackers that can guess your password. There are attackers that can rob you of your phone. But very few can do both, which requires a very targeted attack most people won’t experience.
Shameless self-promo: my April Fool’s joke this year was that the next step after this is to authenticate you by behavior alone since they already track the dickens out of you :-p
http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...
There are attackers that can guess your password. There are attackers that can rob you of your phone. But very few can do both, which requires a very targeted attack most people won’t experience.
Shameless self-promo: my April Fool’s joke this year was that the next step after this is to authenticate you by behavior alone since they already track the dickens out of you :-p
http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...
> The best passwords are truly random strings that are unmemorable
Let's not fool ourselves: those are no longer passwords. A password in the "things that you know" sense of Two Factor must be memorable for it to meet that definition. Which is not that this is bad advice, as it remains great advice: if you must use "passwords" at least use random garbage passwords that you cannot possibly remember and store them somewhere safe such as a Password Manager.
What it does point out is that passwords are broken and have been for some time now. Those of us with the wherewithal to use random garbage backed by password managers have already been living in the "passwordless future". Certainly it is a different "passwordless" than what Microsoft has done, but it is in base principle the exact same thing: using a "something you have" factor (password manager). Certainly a number of specifics differ and in theory if you've bothered to setup your own you are more likely to be using a (unique) strong "pass phrase" as a master key and at least keeping it "something you know by-proxy".
I appreciate the stance that Microsoft's "passwordless" requires you to give Microsoft more control than other options, but I think we need to be very clear that "passwordless" is the goal whether it is "passwordless" via tools such as password manager or "passwordless" via device hardware keys and biometrics engines. Passwords in the traditional sense of "secret you have memorized" have never really worked well and we should get rid of them. (And they were broken long before the bad password policies that Microsoft helped enable that required constant password rotation.)
Let's not fool ourselves: those are no longer passwords. A password in the "things that you know" sense of Two Factor must be memorable for it to meet that definition. Which is not that this is bad advice, as it remains great advice: if you must use "passwords" at least use random garbage passwords that you cannot possibly remember and store them somewhere safe such as a Password Manager.
What it does point out is that passwords are broken and have been for some time now. Those of us with the wherewithal to use random garbage backed by password managers have already been living in the "passwordless future". Certainly it is a different "passwordless" than what Microsoft has done, but it is in base principle the exact same thing: using a "something you have" factor (password manager). Certainly a number of specifics differ and in theory if you've bothered to setup your own you are more likely to be using a (unique) strong "pass phrase" as a master key and at least keeping it "something you know by-proxy".
I appreciate the stance that Microsoft's "passwordless" requires you to give Microsoft more control than other options, but I think we need to be very clear that "passwordless" is the goal whether it is "passwordless" via tools such as password manager or "passwordless" via device hardware keys and biometrics engines. Passwords in the traditional sense of "secret you have memorized" have never really worked well and we should get rid of them. (And they were broken long before the bad password policies that Microsoft helped enable that required constant password rotation.)
This was the realization that made me backburner my physical password manager project https://github.com/jareklupinski/zamek
I'm more interested in exploring ways to ease the burden of "thing you know" for a lossy human mind, than racing to the bottom of "thing you have" with a bunch of other hardware vendors.
So far I really like those spinning wheel codexes you can keep on a keychain :) Looks random to everyone else but only I know the exact pattern to turn jumble into password.
I'm more interested in exploring ways to ease the burden of "thing you know" for a lossy human mind, than racing to the bottom of "thing you have" with a bunch of other hardware vendors.
So far I really like those spinning wheel codexes you can keep on a keychain :) Looks random to everyone else but only I know the exact pattern to turn jumble into password.
You would still login to your password manager using a (human memorable) password, so that would still count as something that you know ;) (it's true though that many password managers will allow you to use some second factor to login)
Yes I mentioned that many password manager setups are at least "something you know by-proxy" if you have a password/pass phrase associated. (Keep in mind not all password managers require that, such as the default ones in most browsers.)
> Those of us with the wherewithal to use random garbage backed by password managers
...have documented all of the sites we visit and all of the authentication for them in one convenient package?
Don't get me wrong, I use a password manager too but it's mostly because of the inconsistent password requirements most sites have making using the same password for all of them impossible.
If someone compromises my password manager then they have access to even more information than if they had a single password for all the sites I use.
...have documented all of the sites we visit and all of the authentication for them in one convenient package?
Don't get me wrong, I use a password manager too but it's mostly because of the inconsistent password requirements most sites have making using the same password for all of them impossible.
If someone compromises my password manager then they have access to even more information than if they had a single password for all the sites I use.
Offline password manager. Keepass. Downside is it's up to you to not lose the data.
If you use one password and it leaks, it's almost as bad as leaking a password manager. The attacker can just try it out on all the sites they care about. And it's much more likely to happen.
Yes that's absolutely true. I know this isn't true of everyone but I personally use a unique email address for every site I engage with making it less likely, though not impossible, for something like that to happen.
Absolutely. Depending on your threat model a password manager is exactly the same sort of "single point of failure" as Microsoft's "passwordless" implementation with a worse added huge information disclosure risk on a successful attack.
It's more reason I consider our current collective "password" approach broken. Passwords don't scale at a human level and password managers full of "random garbage" passwords are a great workaround for that, but they have their own threat models and risks and accidental information disclosures to worry about. I believe we need to keep in mind that it is a workaround.
It's more reason I consider our current collective "password" approach broken. Passwords don't scale at a human level and password managers full of "random garbage" passwords are a great workaround for that, but they have their own threat models and risks and accidental information disclosures to worry about. I believe we need to keep in mind that it is a workaround.
That's why you still use a decently long passphrase and use an offline password manager.
This is the #1 reason I am all in on Chrome even though I don't really want to be. I'd like to be using some other Chromium based browser, but I can't really leave my passwordless life, and Chrome makes it all too easy to sync my garbage passwords across all devices with Chrome installed (which is available pretty much everywhere).
Bitwarden is really good for this also. I had the same concerns before I started using it! Works great on mobile too
You can use a Keepass database synced across devices with iCloud, etc. That lets you escape the Chrome spyware dependency. Keepass extensions integrate well with all browsers, even those on iOS.
Firefox has the same feature, i have been more firefox user since Chrome was hanging my system sometime ago
Brave, Firefox, and I believe Opera all do this also. I use Brave everywhere for the adblocking, but same gist. I get aggravated anymore when I find a site that I don't have credentials stored, or that refuse to work with Brave(looking at you, US Bank).
Except that password managers still need "something you know" to get access, a password. That's why one of the most popular managers is called 1Password.
I did mention that in some cases it is at best "something you know by-proxy".
Keep in mind though: the average user that uses any password manager installed in their browser. If they've turned on password sync they've got it connected to their Apple/Firefox/Microsoft/Google account (and its username/password/what-have-you), but by default the browser as a password manager in most browsers does not require a login of any sort and does not require a "master password" or "master key phrase".
Keep in mind though: the average user that uses any password manager installed in their browser. If they've turned on password sync they've got it connected to their Apple/Firefox/Microsoft/Google account (and its username/password/what-have-you), but by default the browser as a password manager in most browsers does not require a login of any sort and does not require a "master password" or "master key phrase".
I think most mac browsers use the keyring, and I know chrome on windows uses CryptProtectData which is fine. Those both depend on your login password. Firefox won't be secure by default but the average user isn't on Firefox these days.
> A password in the "things that you know" sense of Two Factor must be memorable for it to meet that definition.
You've never memorized a random garbage password? Passwords don't have to be memorable.
(Unless by 'memorable' you mean 'able to be memorized', in which case all random strings are 'memorable'.)
You've never memorized a random garbage password? Passwords don't have to be memorable.
(Unless by 'memorable' you mean 'able to be memorized', in which case all random strings are 'memorable'.)
Sure, a person can memorize one, maybe a dozen "random garbage" passphrases in their life-time. It doesn't scale from a human perspective to one-per-site, which is why to follow that advice you *have to* use a password manager at which point they aren't memorable/things you know, they are things you have (in a passsword manager).
A password manager ties them all together into one thing you know, but it's still a thing you know. The database by itself will be useless under a reasonable configuration.
That's why I said it was at best "something you know by-proxy". It isn't "something you know" that you share with either the IdP or the RP, but "something you know" that you share with "something you have" (your password manager), which in this case is a proxy known to neither your IdP nor your RP in most scenarios. It's a useful workaround to have "something you know by-proxy", but it doesn't really meet the strict definition of the factor.
A password manager is not the only solution. A memorized good-enough hash function operating on (fixed-salt, service provider's name, possibly a salt storable in plaintext perhaps accessible to public)->unique password is very strong for most people and is more portable than a password manager.
> most people
I think you dramatically overestimate how many people can do this consistently for years on end. People who don't use a password manager simply reuse passwords. That's what they've always done. Any solution that ignores this observation is doomed to fail.
I think you dramatically overestimate how many people can do this consistently for years on end. People who don't use a password manager simply reuse passwords. That's what they've always done. Any solution that ignores this observation is doomed to fail.
I disagree, since I think it has more to do with lack of education that this is something you can do; have a simple deterministic algorithm for generating passwords based on your service. It's far more convenient than a password manager, and can avoid the single-point-of-failure.
>Passwords in the traditional sense of "secret you have memorized" have never really worked well and we should get rid of them.
No, we shouldn't. Passwords, as they are allow me to use whatever means I choose to remember the key. I can memorize the password, I can use a password manager or I can even derive the password based on some rules I've made up. The choice is mine. A passwordless future is almost certainly going to remove that choice from me.
If you told me that in 30 years you need to insert your national ID card into your computer to log in or to browse the web, I would believe you. And I would much rather have broken things instead of that kind of dystopic future.
No, we shouldn't. Passwords, as they are allow me to use whatever means I choose to remember the key. I can memorize the password, I can use a password manager or I can even derive the password based on some rules I've made up. The choice is mine. A passwordless future is almost certainly going to remove that choice from me.
If you told me that in 30 years you need to insert your national ID card into your computer to log in or to browse the web, I would believe you. And I would much rather have broken things instead of that kind of dystopic future.
It's a lovely illusion of choice, yes.
I'd personally rather see us invest time in "passwordless" systems that provide their own choices/alternatives, but in a collectively strong way where the weakest link in our security chains aren't bad password policies and massive password leaks from database compromises.
(How many banks still require passwords that have no symbols in them because they are overly afraid of injection hacks and would rather have users use weaker passwords? How sites in general still require tiny passwords because of choices in varchar(16) that haunt them to this day, or worse COBOL tools with exact sized binary fields that still need to have those passwords in them? How many sites do we need to see added to the database of something like pwnedpasswords/haveibeenpwned before enough is enough?)
I'm absolutely not saying that Microsoft's approach to "passwordless" is the best one, and certainly "national ID card" is a very scary straw-man that comes up a lot in these discussions!
I am saying that we have to start from the perspective of passwords are broken for us the power users (and our lovely workaround the modern password manager) just as much as for average users that don't understand what is going on technically. We need to get rid of passwords. If we work together today we can try to build standards that get rid of passwords and still provide (especially for power users) provider choice and hardware choice and all of the little things like that which matter to us.
Pretending passwords aren't broken isn't going to get us there, and is more likely to get you that future dystopia where you have no choice rather than appreciating today that passwords need to go and we should be working together on the solutions (twenty years ago) and rather than arguing to maintain the (broken) status quo, now is still a great time to explore and propose alternatives.
I'd personally rather see us invest time in "passwordless" systems that provide their own choices/alternatives, but in a collectively strong way where the weakest link in our security chains aren't bad password policies and massive password leaks from database compromises.
(How many banks still require passwords that have no symbols in them because they are overly afraid of injection hacks and would rather have users use weaker passwords? How sites in general still require tiny passwords because of choices in varchar(16) that haunt them to this day, or worse COBOL tools with exact sized binary fields that still need to have those passwords in them? How many sites do we need to see added to the database of something like pwnedpasswords/haveibeenpwned before enough is enough?)
I'm absolutely not saying that Microsoft's approach to "passwordless" is the best one, and certainly "national ID card" is a very scary straw-man that comes up a lot in these discussions!
I am saying that we have to start from the perspective of passwords are broken for us the power users (and our lovely workaround the modern password manager) just as much as for average users that don't understand what is going on technically. We need to get rid of passwords. If we work together today we can try to build standards that get rid of passwords and still provide (especially for power users) provider choice and hardware choice and all of the little things like that which matter to us.
Pretending passwords aren't broken isn't going to get us there, and is more likely to get you that future dystopia where you have no choice rather than appreciating today that passwords need to go and we should be working together on the solutions (twenty years ago) and rather than arguing to maintain the (broken) status quo, now is still a great time to explore and propose alternatives.
> It's a lovely illusion of choice, yes.
It's not an illusion. There is no model where a 3rd party is involved that isn't pre-compromised, either legally (the government and civil actors via the courts), financially (stop paying, lose access), operationally (so sorry, your key expired), logistically (oh, sorry, our server is down. Can't load your keyring), or technically (um... this device thingy stopped working). Every one of these problems is really a showstopper when it comes down to it. Why? Because without perfect performance of third parties and/or hardware, the risk is your data being locked away forever (or even for a few days). We all accept some of these realities, but ultimately, I think most of us on HN have had one of the above happen to us (maybe all of the above).
> How many sites do we need to see added to the database of something like pwnedpasswords/haveibeenpwned before enough is enough?)
I'd love a way to get rid of the password, but the trade off is either having a third party control access to my computer or counting on flawless reliability of people and hardware. All of which can lead to a worse state than cracked: data lost forever.
Ultimately, disclosures are terrible, horrible and should be prevented. But permanent loss of access is even more horrible.
It's not an illusion. There is no model where a 3rd party is involved that isn't pre-compromised, either legally (the government and civil actors via the courts), financially (stop paying, lose access), operationally (so sorry, your key expired), logistically (oh, sorry, our server is down. Can't load your keyring), or technically (um... this device thingy stopped working). Every one of these problems is really a showstopper when it comes down to it. Why? Because without perfect performance of third parties and/or hardware, the risk is your data being locked away forever (or even for a few days). We all accept some of these realities, but ultimately, I think most of us on HN have had one of the above happen to us (maybe all of the above).
> How many sites do we need to see added to the database of something like pwnedpasswords/haveibeenpwned before enough is enough?)
I'd love a way to get rid of the password, but the trade off is either having a third party control access to my computer or counting on flawless reliability of people and hardware. All of which can lead to a worse state than cracked: data lost forever.
Ultimately, disclosures are terrible, horrible and should be prevented. But permanent loss of access is even more horrible.
> There is no model where a 3rd party is involved that isn't pre-compromised, either legally (the government and civil actors via the courts), financially (stop paying, lose access), operationally (so sorry, your key expired), logistically (oh, sorry, our server is down. Can't load your keyring), or technically (um... this device thingy stopped working). Every one of these problems is really a showstopper when it comes down to it. Why? Because without perfect performance of third parties and/or hardware, the risk is your data being locked away forever (or even for a few days).
This is what I'm saying about password managers. We *are already* in a situation where the best advice we can give each other is to get a 3rd party involved to store our passwords for us because we have to use passwords that we physically cannot remember as humans. Those same 3rd parties have the same complicated issues and responsibilities/trust legally, financially, operationally, logistically, and technically!
Even how many of use Keepass or one of its forks: we accept some technical trade-offs ("It's open source!") for some massive legal ones. I tried to describe Keepass to my father and as an attorney he shivered in horror at the thought that there was no legal entity to hold accountable (through the courts if need be, through the Better Business Bureau and the court of public opinion at the very least) should things go wrong. My father wasn't wrong about that, and I've thought about that additional perspective for years now without good answers.
That's also why I describe the above "choice" as an illusion of choice: our best security advice is that the safest passwords are already out of physical human memory (between minimum complexity requirements to avoid spray attacks and minimum uniqueness complexity to avoid reuse attacks) so remembering all of our passwords is just out. There are plenty of HN posts about algorithmic "passwords" that people can sort of memorize, but no algorithm can match the practical problem of the wide variety of different password policies across the web. The only real, practical option we have as a best practice is Password Managers. Which I want to make clear are already "3rd Party passwordless": and there we do have real choices right now between 3rd Party providers. I want to make it clear that just because I think passwords are broken I don't think choice is bad: I want us to understand as a group that the real fight isn't between "password managers" and "passwordless", because "password managers" are a workaround/hack towards "passwordless". The existing diversity in password managers is good, I don't know how we keep that in more "passwordless" systems, but I don't think we get there by championing for the "password" status quo. We can try to throw out the "password" bath water without throwing out the "password manager" baby, but mostly only if we start by agreeing that "passwords" are broken.
This is what I'm saying about password managers. We *are already* in a situation where the best advice we can give each other is to get a 3rd party involved to store our passwords for us because we have to use passwords that we physically cannot remember as humans. Those same 3rd parties have the same complicated issues and responsibilities/trust legally, financially, operationally, logistically, and technically!
Even how many of use Keepass or one of its forks: we accept some technical trade-offs ("It's open source!") for some massive legal ones. I tried to describe Keepass to my father and as an attorney he shivered in horror at the thought that there was no legal entity to hold accountable (through the courts if need be, through the Better Business Bureau and the court of public opinion at the very least) should things go wrong. My father wasn't wrong about that, and I've thought about that additional perspective for years now without good answers.
That's also why I describe the above "choice" as an illusion of choice: our best security advice is that the safest passwords are already out of physical human memory (between minimum complexity requirements to avoid spray attacks and minimum uniqueness complexity to avoid reuse attacks) so remembering all of our passwords is just out. There are plenty of HN posts about algorithmic "passwords" that people can sort of memorize, but no algorithm can match the practical problem of the wide variety of different password policies across the web. The only real, practical option we have as a best practice is Password Managers. Which I want to make clear are already "3rd Party passwordless": and there we do have real choices right now between 3rd Party providers. I want to make it clear that just because I think passwords are broken I don't think choice is bad: I want us to understand as a group that the real fight isn't between "password managers" and "passwordless", because "password managers" are a workaround/hack towards "passwordless". The existing diversity in password managers is good, I don't know how we keep that in more "passwordless" systems, but I don't think we get there by championing for the "password" status quo. We can try to throw out the "password" bath water without throwing out the "password manager" baby, but mostly only if we start by agreeing that "passwords" are broken.
>This is what I'm saying about password managers. We are already in a situation where the best advice we can give each other is to get a 3rd party involved to store our passwords for us because we have to use passwords that we physically cannot remember as humans
Nope. Not the case. I'm pretty sure I log into my password manager with.... a password.
Nope. Not the case. I'm pretty sure I log into my password manager with.... a password.
This sounds like corporate propaganda. The way I can tell is that it tries to convince people to surrender their freedom using arguments such as "What is freedom?", "There is no other option" or "Alternatives are illusions" - These narratives just try to brainwash us into a "Freedom is slavery" mindset described by Orwell.
[deleted]
This is an extremely bad take. Instead of standing up a hypothetical strawman, let's look at what Microsoft has actually replaced the password with. There are quite a few, ahem, choices.
From the blog post the article cites, those options are: Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email. Note that Windows hello is also carrying a lot of water here, as that's facial recognition, pin, pattern, or fingerprint.
The biggest place that the password argument falls apart is, these choices are not exclusive. You can use any combination of them that you want. You can use multiple of the same option i.e. security keys or fingerprints.
From the blog post the article cites, those options are: Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email. Note that Windows hello is also carrying a lot of water here, as that's facial recognition, pin, pattern, or fingerprint.
The biggest place that the password argument falls apart is, these choices are not exclusive. You can use any combination of them that you want. You can use multiple of the same option i.e. security keys or fingerprints.
Okay, and I don't want to install an app, don't want "Windows Hello" to have my face, don't have a "security key" and don't want to give Microsoft my phone number.
All of these options seem to have a damning tendency to compromise your privacy in one way or another.
Passwords remain the best option for privacy, especially when a company refuses to implement TOTP.
All of these options seem to have a damning tendency to compromise your privacy in one way or another.
Passwords remain the best option for privacy, especially when a company refuses to implement TOTP.
I'm OK with having a security key, and actually have one (YubiKey).
But MS went out of their way to only allow using it under Windows for some reason. If you want to log in to Azure/Office 365 from a different OS, you have to use some other way.
> especially when a company refuses to implement TOTP.
They do have TOTP, though. It's called "Authenticator app". The one that does the push notification and is MS-only is called "Microsoft authenticator" in their list. This works both on my personal, basic "outlook.com" account and on my work Azure / Office 365 one.
---
What I find funny is that for the personal account, the push notification seems better implemented: they send a code that's also on the screen, so you can know that you're approving the action you're currently doing. On the Office 365 subscription, I just get an "approve / cancel" box. This could probably be abused by someone knowing that I'm about to log in, since I have no way of knowing what I'm approving.
But MS went out of their way to only allow using it under Windows for some reason. If you want to log in to Azure/Office 365 from a different OS, you have to use some other way.
> especially when a company refuses to implement TOTP.
They do have TOTP, though. It's called "Authenticator app". The one that does the push notification and is MS-only is called "Microsoft authenticator" in their list. This works both on my personal, basic "outlook.com" account and on my work Azure / Office 365 one.
---
What I find funny is that for the personal account, the push notification seems better implemented: they send a code that's also on the screen, so you can know that you're approving the action you're currently doing. On the Office 365 subscription, I just get an "approve / cancel" box. This could probably be abused by someone knowing that I'm about to log in, since I have no way of knowing what I'm approving.
> But MS went out of their way to only allow using it under Windows for some reason. If you want to log in to Azure/Office 365 from a different OS, you have to use some other way.
According to Microsoft’s documentation, windows, macOS and Linux are all supported, but only edge and chrome on macOS and only chrome on Linux. https://docs.microsoft.com/en-us/azure/active-directory/auth...
When we implemented this lately, we did find another somewhat annoying speedbump: If you use SAML-based SSO and log in with a yubikey, some SSO breaks since the application at the other end requires explicit password-based authentication. Fixing this requires assistance from the application provider who may be unwilling to fix this.
According to Microsoft’s documentation, windows, macOS and Linux are all supported, but only edge and chrome on macOS and only chrome on Linux. https://docs.microsoft.com/en-us/azure/active-directory/auth...
When we implemented this lately, we did find another somewhat annoying speedbump: If you use SAML-based SSO and log in with a yubikey, some SSO breaks since the application at the other end requires explicit password-based authentication. Fixing this requires assistance from the application provider who may be unwilling to fix this.
Interesting, can confirm Chrome works on Linux.
What's weird is that Teams on Linux does show the "sign in with security key" but it doesn't do anything.
What's weird is that Teams on Linux does show the "sign in with security key" but it doesn't do anything.
[deleted]
The argument that Microsoft is somehow to blame for wanting you to either give them your phone number or buy a $10 security key before giving you access to their free online email and services is...weird?
Like, it's pretty normal for such services to demand phone numbers. Like Signal does.
If you don't like it, you can use something else? I fail to see what the big deal is here.
Like, it's pretty normal for such services to demand phone numbers. Like Signal does.
If you don't like it, you can use something else? I fail to see what the big deal is here.
Microsoft owns the computer industry. "Use something else" is quite a weak argument in markets dominated by oligopolies and especially in this one. At the very most, the argument would be "use the other one".
Passwords are broken, now give us your face for facial recognition. Facial recognition is broken, now etc etc
Passwords are broken, now give us your face for facial recognition. Facial recognition is broken, now etc etc
I don't think I've used a single microsoft product in like six or seven years. Docs has replaced Word and Excel. I own a Mac and prior to that I owned a linux machine. I use Zoom and FaceTime for video calls. I don't even use github.
This is a strange argument, to me. I don't have any devices made by Microsoft, and have not for years. And I'm lazy and disinclined towards "linux on the desktop" neckbeardism. ;)
Congratulations. Microsoft Windows, Microsoft Exchange, Microsoft Word, Microsoft Teams, Microsoft Excel, etc etc.
MacOS/Chrome os, iCloud/Gmail, Google docs, zoom/whatever Hangouts is called today/discord, Google sheets.
It's not even that hard to avoid Microsoft.
It's not even that hard to avoid Microsoft.
It's difficult in corporations, but not at home.
> you can use something else
This is quite simply not true, Microsoft is a monopolist.
> $10 security key
You're implying this is somehow little, even though spending $10 to comply with another weird demand from yet another US corp that feels I have to spend or compromise myself to conform to their demands is too much. Any amount of money is too much, and any amount of compromise is too.
This is quite simply not true, Microsoft is a monopolist.
> $10 security key
You're implying this is somehow little, even though spending $10 to comply with another weird demand from yet another US corp that feels I have to spend or compromise myself to conform to their demands is too much. Any amount of money is too much, and any amount of compromise is too.
>any amount of compromise is too
I would argue you _are_ compromising. You're accepting the drawbacks of passwords in exchange for not having to use any of the alternatives.
I would argue you _are_ compromising. You're accepting the drawbacks of passwords in exchange for not having to use any of the alternatives.
>Like, it's pretty normal for such services to demand phone numbers. Like Signal does.
>If you don't like it, you can use something else?
We can also demand that they keep using passwords. Signal, for example, is a complete non-starter for me because of that phone number requirement. As long as they have that requirement I will never use their service.
Also, that $10 security key is just a step away from being your national ID card. That's how bank logins work here. No passwords allowed.
>If you don't like it, you can use something else?
We can also demand that they keep using passwords. Signal, for example, is a complete non-starter for me because of that phone number requirement. As long as they have that requirement I will never use their service.
Also, that $10 security key is just a step away from being your national ID card. That's how bank logins work here. No passwords allowed.
> Also, that $10 security key is just a step away from being your national ID card. That's how bank logins work here. No passwords allowed.
Er, wouldn't that be a good thing? Identities cannot be linked to the same physical FIDO key across multiple relying parties, so what's the concern?
Er, wouldn't that be a good thing? Identities cannot be linked to the same physical FIDO key across multiple relying parties, so what's the concern?
Yes, that is how the crypto works from a technical perspective.
But the places that want to know your identity for casual surveillance will not settle for just a pseudonymous FIDO exchange. What will happen is there will be a handful of companies that you directly authenticate to with FIDO (eg Google), who require a bunch of personal information to create an account, that then vouch for your larger identity to third parties.
The problem is not technical - there are many ways to replace website auth passwords that would be better. The problem is the business desires all but guarantee newly developed methods will leak more of our personal information. Is a business more likely to do the work of implementing FIDO themselves, or to tie into Sign in with Bigcorp? Given what is already happening, that answer is clear.
Simple per-site passwords continue to exist due to the momentum of everyone understanding them, despite their drawbacks for the surveillance industry. Regardless of what other methods are offered, we should aim to preserve the existence of the password method as at least one of the choices, such that we can freely decide whether those other methods actually benefit us. The growing insistence on snake oil "2FA" is already bad enough.
But the places that want to know your identity for casual surveillance will not settle for just a pseudonymous FIDO exchange. What will happen is there will be a handful of companies that you directly authenticate to with FIDO (eg Google), who require a bunch of personal information to create an account, that then vouch for your larger identity to third parties.
The problem is not technical - there are many ways to replace website auth passwords that would be better. The problem is the business desires all but guarantee newly developed methods will leak more of our personal information. Is a business more likely to do the work of implementing FIDO themselves, or to tie into Sign in with Bigcorp? Given what is already happening, that answer is clear.
Simple per-site passwords continue to exist due to the momentum of everyone understanding them, despite their drawbacks for the surveillance industry. Regardless of what other methods are offered, we should aim to preserve the existence of the password method as at least one of the choices, such that we can freely decide whether those other methods actually benefit us. The growing insistence on snake oil "2FA" is already bad enough.
To restate, I think your argument is that by making authn more complex, standards like WebAuthn will push towards "Identity as a Service" platforms like Firebase, Okta, etc, and that this concentrates power in the hands of those providers.
To an extent I think this is a fair argument, but it strikes me as somewhat of a Luddite one as well: yes, the better technology is also more complex, but most of the time users are simply more secure by developers choosing IaaS providers!
At the limit, you could argue against developer guidelines to use SSL or salted password storage, because those are "complex" and "encourage adoption of common providers." I don't think these security mechanisms are significant drivers of tech consolidation, and of all the things to complain about, the payoff for users--increased security--is hard to oppose!
To an extent I think this is a fair argument, but it strikes me as somewhat of a Luddite one as well: yes, the better technology is also more complex, but most of the time users are simply more secure by developers choosing IaaS providers!
At the limit, you could argue against developer guidelines to use SSL or salted password storage, because those are "complex" and "encourage adoption of common providers." I don't think these security mechanisms are significant drivers of tech consolidation, and of all the things to complain about, the payoff for users--increased security--is hard to oppose!
When it comes to surveillance companies developing software, I am a Luddite by default. They can't help but incorporate biases that destroy end user autonomy, because they're only concerned about advancing their own perspective. In general, I don't view "security" under the wing of a company as a goal worth striving for, because companies are the long-term attackers we need to worry about!
If it was guaranteed that say FIDO would stop sites demanding phone numbers to do snake oil "2FA", then I'd be fully supportive. But from what I've witnessed surveillace companies won't take steps that don't benefit them - why would they ever stop demanding phone numbers now that they can? And so whatever it turns out being, I can only imagine that "passwordless" will be similarly abused ("never let a good crisis go to waste"). At the very least it will create another configuration speed bump that interrupts workflows based around trying to compartmentalize the surveillance industry (eg I only run web browsers in VMs).
If you really want to drive adoption of FIDO, then instead of pushing hardware tokens (and corresponding heavyweight process), Mozilla should create a software FIDO key within the browser. That is something that I can see evolving features that help users rather than restrict them. It would then be up to an end user whether to use a hardware token in place of that, iff they determine that a given account is that important.
If it was guaranteed that say FIDO would stop sites demanding phone numbers to do snake oil "2FA", then I'd be fully supportive. But from what I've witnessed surveillace companies won't take steps that don't benefit them - why would they ever stop demanding phone numbers now that they can? And so whatever it turns out being, I can only imagine that "passwordless" will be similarly abused ("never let a good crisis go to waste"). At the very least it will create another configuration speed bump that interrupts workflows based around trying to compartmentalize the surveillance industry (eg I only run web browsers in VMs).
If you really want to drive adoption of FIDO, then instead of pushing hardware tokens (and corresponding heavyweight process), Mozilla should create a software FIDO key within the browser. That is something that I can see evolving features that help users rather than restrict them. It would then be up to an end user whether to use a hardware token in place of that, iff they determine that a given account is that important.
There's nothing that stands in the way of anyone implementing a software FIDO2 key (though some RPs can reject self-signed attestation certs if they want to, but it's not common AFAIK).
See https://github.blog/2017-07-20-soft-u2f/ for an example.
See https://github.blog/2017-07-20-soft-u2f/ for an example.
I didn't say there was, and I figured there had to be, given the amount of open implementations. I was speaking more to adoption path and resulting customs rather than what is technically possible. Like for example to use "FIDO authentication", if I have to plug in a specific USB key, pass it through to a VM, etc, then that extra effort isn't worth it for 90% of my accounts (although that won't stop them from insisting that it is!). Whereas if Firefox can handle it in software by default, and I can easily backup/restore its keying material with standard shell scripts, then I'm much more likely to see it as a benefit.
FWIW do you know if the server can reliably determine what brand of authenticator is being used (eg through a pubkey signature)? I haven't studied the protocol enough to know if it contains those kind of anti-features.
FWIW do you know if the server can reliably determine what brand of authenticator is being used (eg through a pubkey signature)? I haven't studied the protocol enough to know if it contains those kind of anti-features.
> Identities cannot be linked
Yes, they can. Quite obviously they can and all it takes is even a modicum of cooperation. We have already extensively seen corporations love to cooperate when it comes to compromising information that belongs to you.
Yes, they can. Quite obviously they can and all it takes is even a modicum of cooperation. We have already extensively seen corporations love to cooperate when it comes to compromising information that belongs to you.
Compliant FIDO2 keys guarantee unlinkability even against colluding relying parties. See https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-se..., specifically "security goal 4", and the unique authentication keys requirement.
Against any two, not any number.
Did you look at how this is actually achieved?
Attackers (even if they control several major outfits like say Microsoft) are not going to succeed in a correlation attack. Roughly what they're doing is like trying to guess the AES keys.
This is in stark contrast to passwords of course, where correlation is so high that haveibeenpwned is worth existing...
Attackers (even if they control several major outfits like say Microsoft) are not going to succeed in a correlation attack. Roughly what they're doing is like trying to guess the AES keys.
This is in stark contrast to passwords of course, where correlation is so high that haveibeenpwned is worth existing...
Seriously?
Please, explain to me how an arbitrary number of RPs can collude to link a FIDO2 identity.
Please, explain to me how an arbitrary number of RPs can collude to link a FIDO2 identity.
You are compromising security here.
Windows Hello is basically the same thing as how you unlock your phone with Apple or Android. --Your biometric data doesn't leave your device, instead it's used to unlock a certificate in a TPM. I'm not sure how that's supposed to compromise your privacy.
Though it can easily fall prey to the same problem as the security key: my machine doesn't have any biometric inputs, so I'm at least back to "buy something."
PIN, pattern, phone app.
If those are three different things, and I can choose one of those, why a four number PIN code would be safer than a password?
Microsoft's "PIN" is not a four-number digit code, it's an arbitrary-length device passphrase that can include all symbols found on your keyboard. The only reason they don't call it a password is because you already have a (global) account password, and the PIN only serves to unlock that device. If you have two devices, you can have a different PIN for both, that will still log you into the same account.
Critically they don't know the PIN and so can't lose it. When you use your global Microsoft account login they know the password. Now, if they're careful they immediately forget it after verifying it, and it's hard to steal the authentication credentials they keep, and so on. But you're relying on them being unfailingly careful there. Whereas, for the PIN even if Microsoft screws up they don't know it and can't lose it.
FIDO 2FA is safer because both factors stay where you are, the FIDO device promises it checked the other factor. The FIDO device is something you have, while your other factor (like a PIN, something you know, or a fingerprint, something you are) it vouches for by signing a bitflag labelled UV User Verified. This flag says, I promise I verified this is the same human that we originally enrolled. Which human? Not something the FIDO device knows or cares about and so it can't tell the Relying Party anything they didn't already tell it about who was enrolled. How did it check? Not revealed to the Relying Party.
FIDO 2FA is safer because both factors stay where you are, the FIDO device promises it checked the other factor. The FIDO device is something you have, while your other factor (like a PIN, something you know, or a fingerprint, something you are) it vouches for by signing a bitflag labelled UV User Verified. This flag says, I promise I verified this is the same human that we originally enrolled. Which human? Not something the FIDO device knows or cares about and so it can't tell the Relying Party anything they didn't already tell it about who was enrolled. How did it check? Not revealed to the Relying Party.
Because it is tied to a specific device and is not global like a password is.
> Windows Hello is basically the same thing as how you unlock your phone with Apple or Android.
People have option to use codes.
People have option to use codes.
Windows Hello supports PINs and/or patterns in addition to biometrics.
[deleted]
[deleted]
PIN.
> From the blog post the article cites, those options are: Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email.
Mmm, yup that all sounds terrible. I agree with GP, I like the ability to decide how to manage logging in.
Passwords are a "least worst" kind of system.
Mmm, yup that all sounds terrible. I agree with GP, I like the ability to decide how to manage logging in.
Passwords are a "least worst" kind of system.
Passwords are a lowest common denominator kind of system. They're an unstructured primitive that people can add structure to in order to create a system. Everyone ad-hoc creates their own and most people are really bad at it. Whether it's memorization, deriving them from some other key, storing them in a HSM, or in a password manager.
Exactly, they are the primitives of security systems. If passwords are broken, then every other security system is suspect. If users can't be trusted with passwords because most people are really bad at it, and people are bad at it because they are human, why should I trust MS's human developers to do any better? Why should I trust anyone to do better? Exploitable software has resulted in far more economic damage than bad passwords.
It seems like a massive XY problem where somehow many people have come to the Y "let's get rid of passwords" as the solution, when the X is a mixture of solved problems:
- "people are bad at entropy" (password gens, sensible entropy rules)
- "people are bad at memorizing orthogonal unique strings" (password management schemes and systems)
- "passwords leak" (detect wild passwords and facilitate rotation)
The humble "secure string" allows the implementation gamut from "hunter2" to kilobits of noise, stored in a browser, chip, or post-it. Just prevent the worst incarnations. Passwords are not broken.
It seems like a massive XY problem where somehow many people have come to the Y "let's get rid of passwords" as the solution, when the X is a mixture of solved problems:
- "people are bad at entropy" (password gens, sensible entropy rules)
- "people are bad at memorizing orthogonal unique strings" (password management schemes and systems)
- "passwords leak" (detect wild passwords and facilitate rotation)
The humble "secure string" allows the implementation gamut from "hunter2" to kilobits of noise, stored in a browser, chip, or post-it. Just prevent the worst incarnations. Passwords are not broken.
> Exactly, they are the primitives of security systems. If passwords are broken, then every other security system is suspect. If users can't be trusted with passwords because most people are really bad at it, and people are bad at it because they are human, why should I trust MS's human developers to do any better?
Passwords that are managed by hand are broken. If you’re already using an automated password manager, then you’re probably fine. Humans can build tools that do stuff better than unassisted humans can do it. Cars are faster than humans, even though humans built them. Dice are better at generating random numbers than unassisted humans, and they’re literally just marked cubes.
Of course, the Windows end-users could build software-based password managers instead of doing it by hand, and some have. But it’s not the default, so many don’t.
> Why should I trust anyone to do better? Exploitable software has resulted in far more economic damage than bad passwords.
You seem to be underestimating the amount of economic damage caused by phishing and password reuse, both of which can be largely chalked up to manual password management. But am willing to be corrected on this. [citation needed]
Passwords that are managed by hand are broken. If you’re already using an automated password manager, then you’re probably fine. Humans can build tools that do stuff better than unassisted humans can do it. Cars are faster than humans, even though humans built them. Dice are better at generating random numbers than unassisted humans, and they’re literally just marked cubes.
Of course, the Windows end-users could build software-based password managers instead of doing it by hand, and some have. But it’s not the default, so many don’t.
> Why should I trust anyone to do better? Exploitable software has resulted in far more economic damage than bad passwords.
You seem to be underestimating the amount of economic damage caused by phishing and password reuse, both of which can be largely chalked up to manual password management. But am willing to be corrected on this. [citation needed]
Numbers are a bit loose, but even a Fermi style estimation suggests malware in general is worse than phishing. Phishing is on the order of tens of millions [1] to a few billion [2]. Ransomware alone probably causes upwards of many billions [3]. Equifax breach (XML exploit) alone has cost billions. Heartbleed, spectre, meltdown, those are at least 1B each.
[1] https://www.cybersecuritydive.com/news/phishing-cost-enterpr... [2] https://www.proofpoint.com/us/corporate-blog/post/fbi-report... [3] https://cybersecurityventures.com/global-ransomware-damage-c...
[1] https://www.cybersecuritydive.com/news/phishing-cost-enterpr... [2] https://www.proofpoint.com/us/corporate-blog/post/fbi-report... [3] https://cybersecurityventures.com/global-ransomware-damage-c...
Ransomware isn't necessarily spread by software exploits. A lot of them use nothing fancier than "My File.pdf.exe" attached to an email, like CryptoLocker and its many clones [1]. Sure, WannaCry used an actual software exploit, but most ransomware gangs don't have leaked NSA cyberweapons to work with.
[1]: https://www.arnnet.com.au/article/556598/australia-specifica...
Also, a lot of breaches that are caused by vulnerabilities, like large forums having their databases leaked, are bigger problems than they should be thanks to password reuse.
But I hadn't thought of Equifax. That company's database held so much economic value that, all in one fell swoop, this single exploit may have tipped the scale so that vulnerable software cost more than password reuse.
[1]: https://www.arnnet.com.au/article/556598/australia-specifica...
Also, a lot of breaches that are caused by vulnerabilities, like large forums having their databases leaked, are bigger problems than they should be thanks to password reuse.
But I hadn't thought of Equifax. That company's database held so much economic value that, all in one fell swoop, this single exploit may have tipped the scale so that vulnerable software cost more than password reuse.
Indeed. Shit, just this year Microsoft signed a kernel driver containing a rootkit and didn't notice until third parties alerted them three months later. Those are the people you want in control of all your online accounts?
But if you're worried about Microsoft, you shouldn't want a shared secret such as a password. The whole problem with shared secrets is that the other party might lose it.
For WebAuthn, even if Microsoft literally makes a web site "Get tialaramex's authentication credentials here" solely to reveal the credentials they have for me, it doesn't help bad guys at all. Completely useless. The credentials only help Microsoft, and only to verify me.
That's the "scary" passwordless future, authentication that actually works and can't be weaponised against you, terrifying...
For WebAuthn, even if Microsoft literally makes a web site "Get tialaramex's authentication credentials here" solely to reveal the credentials they have for me, it doesn't help bad guys at all. Completely useless. The credentials only help Microsoft, and only to verify me.
That's the "scary" passwordless future, authentication that actually works and can't be weaponised against you, terrifying...
Ugh. I just spent the whole day screwing around trying to debug SAML SSO for setting up a VPN on AWS. Brain is fried and I feel no closer to my goal. I realize that's somewhat unrelated to passwords, but my point is "Identify management is _hard_".
Passwords just kinda work. That's the _opposite_ of broken. We just need to train out the bad habits (storing plaintext, allowing dictionary words, etc).
Passwords just kinda work. That's the _opposite_ of broken. We just need to train out the bad habits (storing plaintext, allowing dictionary words, etc).
How is TOTP terrible? How are security keys terrible?
Parent could be talking more about vendor lock-in rather than protocols.
At least that's my bug bear with this. I know 2FA SMS is less secure, but I'm sticking with it as long as MS require a MS app (or I'm forced off SMS 2FA).
At least that's my bug bear with this. I know 2FA SMS is less secure, but I'm sticking with it as long as MS require a MS app (or I'm forced off SMS 2FA).
MS doesn’t require a MS app unless they’ve changed something recently.
Oh FFS! It's a hidden menu option when you go to [1]. Have to click Configure App Without Notifications once you click Setup Authenticator App.
Two years of misery and stubbornness. One hidden menu option.
[1]: https://account.activedirectory.windowsazure.com/proofup.asp...
Two years of misery and stubbornness. One hidden menu option.
[1]: https://account.activedirectory.windowsazure.com/proofup.asp...
[deleted]
To me a weird part where these hit hard is on shared access to common resources.
The two options I see are either:
- Have shared access baked in the service and each user has its own account, with its own auth means
- Go through elaborate schemes to somewhat share a single account's credentials.
Shared access with multiple accounts is currently a PITA in most services. Apple for instance still doesn't really understand how families work. Google is also suboptimal, even for cases like common photo libraries (not albums, whole libraries), and their weird separation of standard accounts getting access to all services under the sun, and GSuite/Workplace "second class" accounts doesn't help at all. I don't see Microsoft being better on most of its services, but I don't use them enough to have a strong opinion.
So the remaining way to handle these fairly common issues is to have a master account shared among two or more people, and most of these auth options rely on biometrics or fairly personal services. If that's the path forward, I wish they'd clear the surrounding issues first.
The two options I see are either:
- Have shared access baked in the service and each user has its own account, with its own auth means
- Go through elaborate schemes to somewhat share a single account's credentials.
Shared access with multiple accounts is currently a PITA in most services. Apple for instance still doesn't really understand how families work. Google is also suboptimal, even for cases like common photo libraries (not albums, whole libraries), and their weird separation of standard accounts getting access to all services under the sun, and GSuite/Workplace "second class" accounts doesn't help at all. I don't see Microsoft being better on most of its services, but I don't use them enough to have a strong opinion.
So the remaining way to handle these fairly common issues is to have a master account shared among two or more people, and most of these auth options rely on biometrics or fairly personal services. If that's the path forward, I wish they'd clear the surrounding issues first.
You can enroll multiple fingers, you can enroll multiple security keys, you can enroll multiple phone numbers, and you can create and share an account PIN. Choose any combination of these authenticators.
Microsoft also has very mature permissions for all of their web properties like OneDrive and SharePoint/Teams. So you can also give people their own logins and then share stuff between them.
Microsoft also has very mature permissions for all of their web properties like OneDrive and SharePoint/Teams. So you can also give people their own logins and then share stuff between them.
It's actually a good take. They pointed out that you don't need an extra piece of software or device.
PIN.
In two years: PIN deprecated.
Microsoft still supports SMBv1 released in 2003. For the love of God don't use it, but you could.
That's true. But also, how's your Kin/Windows 8 RT device/Windows Phone/Surface Neo/Microsoft eBooks/PlaysForSure music collection?
:-)
:-)
What are my choices for accessing a service that uses Microsoft's "identity platform" / "modern authentication" / (whatever they're calling it now) from a cross-platform desktop client application?
From what I can tell from their ADAL/MSAL documentation, the choices seem to be 1) using Windows with Windows Integrated Authentication (i.e., not cross-platform) or 2) building a web app that redirects to their web-based authentication flow (i.e, not a desktop app).
From what I can tell from their ADAL/MSAL documentation, the choices seem to be 1) using Windows with Windows Integrated Authentication (i.e., not cross-platform) or 2) building a web app that redirects to their web-based authentication flow (i.e, not a desktop app).
So if you lose your phone or are unconscious, say goodbye to your accounts.
Huh? Did you miss the part where you can have multiple options setup at the same time, and use whichever you want whenever you want?
Can I use a password?
This comment reminds me of all the people that open PR in php projects to replace various hashing algorithm with md5, because that one is built-in and obviously superior
Especially in web context the new authentication APIs such as webauthn are long overdue and I'm looking forward to the next generation of password managers that will hopefully keep these generated keys synchronized between devices
Especially in web context the new authentication APIs such as webauthn are long overdue and I'm looking forward to the next generation of password managers that will hopefully keep these generated keys synchronized between devices
MD5 is relatively secure for many applications. You can substitute a few bytes without changing the hash so that leaves some applications for manipulation. It is correct to not use it anymore, but you should know about the specific pitfalls. There is nothing like this for passwords or do you want to elaborate further? A password can even offer superior security in some cases.
You can gladly use webauthn if the service supports it. I just want to keep options. I also dislike synchronizing devices in some cases because that can be a security problem. I also like to compartmentalize some things.
You can gladly use webauthn if the service supports it. I just want to keep options. I also dislike synchronizing devices in some cases because that can be a security problem. I also like to compartmentalize some things.
> MD5 is relatively secure for many applications
This is pure gold.
This is pure gold.
Finding m' from m with the same hash even with an old md5 is not trivial. It has been memed as such, but it is not the case. Don't use it anyway for any application because there are problems and you would need to talk to walls to explain why it can be safe for certain applications. There is a theoretical solution preimage attacks too, but I don't think it was ever demonstrated.
I know this is a lost discussion, but it is technically correct. End of comment.
I know this is a lost discussion, but it is technically correct. End of comment.
You are incorrect. Collisions are trivially easy to create, there is no situation where md5 is a good choice.
Here are sample PIN requirements (you can change them):
Must be a at least 4 characters long. Cannot be longer than 127 characters. Uppercase letters are permitted. Lowercase letters are required. May include digits. Special characters are possible. Cannot be an obvious number pattern (such as 123456 or 111111).
Must be a at least 4 characters long. Cannot be longer than 127 characters. Uppercase letters are permitted. Lowercase letters are required. May include digits. Special characters are possible. Cannot be an obvious number pattern (such as 123456 or 111111).
Something that is unguessable, uniquely yours, and also without the need to memorize or type it in seemed ideal to at least as early as 15 years ago. Biometrics seemed like the obvious choice. I got my little brother a laptop with a fingerprint scanner in 2008. Oh well.
I'm still not unconvinced (in biometrics), but I think carrying something like an electronic keychain (one that I have full control over) is more ideal today.
I'm still not unconvinced (in biometrics), but I think carrying something like an electronic keychain (one that I have full control over) is more ideal today.
The problem with biometrics is that you cannot change them once they're compromised. On top of that, we leave biometric data lying around all the time - your phone is full of your fingerprints. While there might not be great systems to abuse that yet, it does make me hesitate whether biometrics are the way to go.
Biometric data not getting as much legal protection as a password can also cause issues.
Biometric data not getting as much legal protection as a password can also cause issues.
> While there might not be great systems to abuse that yet,
Except I distinctly remember unlocking an iphone with a piece of sellotape a few years ago.
Except I distinctly remember unlocking an iphone with a piece of sellotape a few years ago.
I agree with this 100%. Passwords are awesome. I've never had any security issues related to passwords. They are perfectly secure for almost everyone.
Just because a tiny handful of multi-millionaires feel that passwords are not secure enough for them, doesn't mean that the rest of us should be forced to use a dumb alternative which surrenders control to some third party.
Rule-based passwords are great. I never had any issues. If the rule is secret and complex enough and maps to a different password for each service, this is very secure.
I recommend having a separate rule for different security levels. I have 3 security levels.
- For low security, I use the same rule on 100s of different websites. I don't really care if they all get hacked. (Actually I might use password manager for that security level because I'm lazy and I don't care if some employees at some big company install a backdoor in the password manager steal that password. I'm willing to take that risk.).
- For medium security sites, I use the same rule for around 5 different, highly trustworthy sites... There are literally only 5 sites which I consider 'medium security'.
- For high security, I memorize a unique password or passphrase for each service. I only have 2 services which fit this description of 'high security' - They're financial in nature,.
It's not difficult at all for me to memorize 2 rules and 2 passwords. I don't need to trust any third-party piece of software with my passwords except for my operating system and my browser (both of which are open source BTW).
The idea of password managers is idiotic... You're trusting a single entity with all your passwords! You're assuming that they will never introduce any bug in their code which will leak your passwords to their employees. You're assuming that these companies will never hire malicious developers who will add backdoors to the password manager's code to steal your passwords... No foreign state will try to hack that service... Hackers will hack into gas pipeline companies, but they won't try to hack a massive centralized repository containing everyones' passwords? Think people, think! It's basic common sense.
[EDIT] BTW, the fact that this comment is being downvoted suggests that there may be a corporate agenda behind moving everyone to centralized password managers... Why would the powers that be want to do that?
Just because a tiny handful of multi-millionaires feel that passwords are not secure enough for them, doesn't mean that the rest of us should be forced to use a dumb alternative which surrenders control to some third party.
Rule-based passwords are great. I never had any issues. If the rule is secret and complex enough and maps to a different password for each service, this is very secure.
I recommend having a separate rule for different security levels. I have 3 security levels.
- For low security, I use the same rule on 100s of different websites. I don't really care if they all get hacked. (Actually I might use password manager for that security level because I'm lazy and I don't care if some employees at some big company install a backdoor in the password manager steal that password. I'm willing to take that risk.).
- For medium security sites, I use the same rule for around 5 different, highly trustworthy sites... There are literally only 5 sites which I consider 'medium security'.
- For high security, I memorize a unique password or passphrase for each service. I only have 2 services which fit this description of 'high security' - They're financial in nature,.
It's not difficult at all for me to memorize 2 rules and 2 passwords. I don't need to trust any third-party piece of software with my passwords except for my operating system and my browser (both of which are open source BTW).
The idea of password managers is idiotic... You're trusting a single entity with all your passwords! You're assuming that they will never introduce any bug in their code which will leak your passwords to their employees. You're assuming that these companies will never hire malicious developers who will add backdoors to the password manager's code to steal your passwords... No foreign state will try to hack that service... Hackers will hack into gas pipeline companies, but they won't try to hack a massive centralized repository containing everyones' passwords? Think people, think! It's basic common sense.
[EDIT] BTW, the fact that this comment is being downvoted suggests that there may be a corporate agenda behind moving everyone to centralized password managers... Why would the powers that be want to do that?
FYI, the reason I downvoted was because of your claim that downvoters must be part of some corporate conspiracy to silence you. That's ridiculous.
The truth is that we observe very very clearly that people, as a whole, cannot use sound methods of password management without a password manager. They revert to password reuse. Just because you can do it and it is easy for you does not make this a functional system for ensuring that all users are doing the right thing.
The truth is that we observe very very clearly that people, as a whole, cannot use sound methods of password management without a password manager. They revert to password reuse. Just because you can do it and it is easy for you does not make this a functional system for ensuring that all users are doing the right thing.
Corporations hire hundreds of thousands or even millions of people in management positions whose main purpose is to think about how to increase market share in a world where those corporations already have far more market share than they deserve based on their production ability.
Given this, I think it's normal to expect political manipulation and conspiracies to arise as an alternative to value creation to extract wealth. Remember when Google and Apple agreed not to poach each other's employees? It's irrational to assume that hundreds of thousands of managers just sit around all day doing nothing. It's also irrational to assume that all of these managers are honest, virtuous people. Surely some of them are conspiring with each other across different companies to give themselves an unfair advantage within their respective companies.
Given this, I think it's normal to expect political manipulation and conspiracies to arise as an alternative to value creation to extract wealth. Remember when Google and Apple agreed not to poach each other's employees? It's irrational to assume that hundreds of thousands of managers just sit around all day doing nothing. It's also irrational to assume that all of these managers are honest, virtuous people. Surely some of them are conspiring with each other across different companies to give themselves an unfair advantage within their respective companies.
We should get rid of passwords. Maybe everyone has 1 password to unlock their hardware password manager / login token.
> Let's not fool ourselves: those are no longer passwords. A password in the "things that you know" sense of Two Factor must be memorable for it to meet that definition.
Diceware passwords are actually a great example of passwords that are truly random and unmemorable, yet can be memorized easily
Diceware passwords are actually a great example of passwords that are truly random and unmemorable, yet can be memorized easily
Who's fooling who? This distinction sounds a lot like the "no true password" fallacy. In the common usage, passwords are not as narrowly defined as your usage here. I'm sure you're familiar with the trope of people writing passwords on post-it notes. Would that make it not actually a password? I don't think so. I don't think most other people do either.
I'm definitely not convinced that the brave new password-less future is an improvement. I still don't understand how I'm supposed to log in to the same account on two different devices. WebAuthN and others seem to just punt. "That's the relying party's problem".
It feels a lot to me like I'm slowly getting funneled into some MegaCorp's identity database. No thanks. I'll get rid of my passwords when someone can show me something better.
I'm definitely not convinced that the brave new password-less future is an improvement. I still don't understand how I'm supposed to log in to the same account on two different devices. WebAuthN and others seem to just punt. "That's the relying party's problem".
It feels a lot to me like I'm slowly getting funneled into some MegaCorp's identity database. No thanks. I'll get rid of my passwords when someone can show me something better.
There are decades of computer history telling users that they are never allowed to write a password done on paper or post-it notes. It's not a new "no true password" fallacy, it's a deep one in the history of computing. I think the fact that so many average users are scared to write their passwords down because of bad 1960s security advice is it's own indicator that passwords are broken that can be a long rant to itself.
I don't know if WebAuthN is the answer either. I just know that passwords are broken.
I don't know if WebAuthN is the answer either. I just know that passwords are broken.
People consistently forget the human element when talking about what constitutes "good" security. Sometimes trading a small amount of entropy for a reduction in user friction has the effect of making a system functionally more secure, even if it is hypothetically easier to crack.
It might be easier for Microsoft's new passwordless options to be broken by some good social engineering, but its ease of use over relying on a password manager means users are more likely to abandon that sticky note on their monitor or their re-used easily guessable password.
It might be easier for Microsoft's new passwordless options to be broken by some good social engineering, but its ease of use over relying on a password manager means users are more likely to abandon that sticky note on their monitor or their re-used easily guessable password.
it's really the bad policies that ruined passwords ala https://xkcd.com/936
"This passwordless future requires that Microsoft follow in Apple's and Google's footsteps in deciding which software you are allowed to run on your computer."
"These vendors don't trust you to manage your own security, instead they want you to hand all trust over to them."
"This requirement puts even more control of your hardware into Microsoft's hands."
Whether the concept of the "password" is appropriate for computers doesnt really interest me.
However when companies like Microsoft want to control how I can use a computer, thats a problem.
These proposals are not about "security" in every case, they are about control.
The user could be in a situation where security really isnt a major concern (and thats for the user to decide) but these companies will still be able to control what she can and cannot do.
"These vendors don't trust you to manage your own security, instead they want you to hand all trust over to them."
"This requirement puts even more control of your hardware into Microsoft's hands."
Whether the concept of the "password" is appropriate for computers doesnt really interest me.
However when companies like Microsoft want to control how I can use a computer, thats a problem.
These proposals are not about "security" in every case, they are about control.
The user could be in a situation where security really isnt a major concern (and thats for the user to decide) but these companies will still be able to control what she can and cannot do.
> and thats for the user to decide
I'm getting a vaccination vibe here. If being slack about security means a botnet infection that the rest of us have to deal with, then no, not for the user to decide.
"My computer my choice" only works if you're not connected to a network and can't infect anyone else.
I'm getting a vaccination vibe here. If being slack about security means a botnet infection that the rest of us have to deal with, then no, not for the user to decide.
"My computer my choice" only works if you're not connected to a network and can't infect anyone else.
I'm fully vaccinated. I would bet the Pur.ism folks are vaccinated, too. Vaccination is a government initiative. Microsoft is a private company.
Originaly Windows had no ability to connect to the internet; it was for LANs only. All was well. Gates originally thought the internet made no sense. Then Microsoft added TCP/IP from BSD and people started connecting Windows to the internet. All was not well. Today, Microsoft actually tries to force people to connect to the internet, and stay connected 24/7. They do this with "automatic upgrades/updates". Windows computers will even try to automatically "update" themselves peer-to-peer from other computers on the LAN. Hows that for a virus analogy. Microsoft could never stop botnets targeting Windows proactively so Microsoft became a botnet. They now have remote command and control.
The root cause of botnets isn't the victims, it's the product. Its especially difficult to argue otherwise when owners have less and less control over their own computers.
Originaly Windows had no ability to connect to the internet; it was for LANs only. All was well. Gates originally thought the internet made no sense. Then Microsoft added TCP/IP from BSD and people started connecting Windows to the internet. All was not well. Today, Microsoft actually tries to force people to connect to the internet, and stay connected 24/7. They do this with "automatic upgrades/updates". Windows computers will even try to automatically "update" themselves peer-to-peer from other computers on the LAN. Hows that for a virus analogy. Microsoft could never stop botnets targeting Windows proactively so Microsoft became a botnet. They now have remote command and control.
The root cause of botnets isn't the victims, it's the product. Its especially difficult to argue otherwise when owners have less and less control over their own computers.
I'm fully vaccinated too (and I'm typing this on a Purism 13, so your estimate is good so far ;)
One of the reasons Windows started asserting more and more control over computers is that people are easily duped into doing the wrong thing. I totally agree that Windows was never designed for t'internet, and security was badly bolted on rather than being an integral part from the start. But even if it had been, most of the botnet exploits are social rather than technical. Linux is more secure than Windows, but it is not inherently more proof against social attacks than Windows. However the people who choose to run Linux are more proof against those attacks because we're more knowledgeable about computers, so there are few social attacks that work on Linux.
I'm not victim-blaming. I'm saying some people do not understand the environment they are in or the dangers they face and their bad choices can negatively affect other people around them. Just like with vaccines, mandating some behaviour in this situation seems like a reasonable response.
One of the reasons Windows started asserting more and more control over computers is that people are easily duped into doing the wrong thing. I totally agree that Windows was never designed for t'internet, and security was badly bolted on rather than being an integral part from the start. But even if it had been, most of the botnet exploits are social rather than technical. Linux is more secure than Windows, but it is not inherently more proof against social attacks than Windows. However the people who choose to run Linux are more proof against those attacks because we're more knowledgeable about computers, so there are few social attacks that work on Linux.
I'm not victim-blaming. I'm saying some people do not understand the environment they are in or the dangers they face and their bad choices can negatively affect other people around them. Just like with vaccines, mandating some behaviour in this situation seems like a reasonable response.
Sure, but you're choosing their product, right?
Like, the same argument would suggest that "Who is Microsoft to say I need 256M of RAM to run Windows? If I want to run it on 128M, I should be allowed to do that!"
Like, the same argument would suggest that "Who is Microsoft to say I need 256M of RAM to run Windows? If I want to run it on 128M, I should be allowed to do that!"
> Sure, but you're choosing their product, right?
No, obviously not. They have a dominating market share and I have no choice.
No, obviously not. They have a dominating market share and I have no choice.
> A password in the "things that you know" sense of Two Factor must be memorable for it to meet that definition.
Nonsense - it's even in TFA:
> The best passwords are truly random strings that are unmemorable
"Something you know" isn't necessarily "something you memorised" - I 'know' my credit card number by virtue of having the card but I can't rattle it off on command without looking it up. A password simply has to be information only you have access to - something you know - as opposed to a physical device that generates a token - something you have.
Nonsense - it's even in TFA:
> The best passwords are truly random strings that are unmemorable
"Something you know" isn't necessarily "something you memorised" - I 'know' my credit card number by virtue of having the card but I can't rattle it off on command without looking it up. A password simply has to be information only you have access to - something you know - as opposed to a physical device that generates a token - something you have.
[deleted]
As a regular user of a password manager, my main problem with them is that its just another dependency, and quite an important one, in the chain. If my password manager service goes down, I'm buggered. Of course you could use a paper password manager, but again you could lose that, and also it just gets exponentially more difficult to manage as you add more passwords and get more complex, and most people will eventually start simplifying/reusing their passwords until theres no point in having the manager
I've found passphrases a good middle ground, but truthfully theres again a limit to how many you could remember reliably, causing again reuse. Hence why I'm still using a password manager, it's just not ideal I suppose.
I've found passphrases a good middle ground, but truthfully theres again a limit to how many you could remember reliably, causing again reuse. Hence why I'm still using a password manager, it's just not ideal I suppose.
> If my password manager service goes down, I'm buggered
Most vaults support offline storage.
Most vaults support offline storage.
Yeh thats true, I did think about offline vaults after making this comment but I feel theres still a dependency somewhere.
I guess even if you have offline storage, you still need a way to get that onto other devices. I guess you'd just sign up for a new service.
I guess even if you have offline storage, you still need a way to get that onto other devices. I guess you'd just sign up for a new service.
I keep an offline copy in my safe.
I disagree a bit here. I like passwords and this fad really gets on my nerves. I like to authenticate with a passphrase because easy always wins in computer science. Ever used extended authentication against MS services where you have to register your app to get a specific API key? Me neither because I stopped interfacing them, the hassle was too much.
Passwords aren't that difficult if you have a system which works as a seed to calculate passwords for a service where a leak doesn't allow for conclusions in the other direction. Ok, not that easy, but manageable. You could use a std password and append the name of the service and in most cases that would suffice if your plaintext pwds don't leak.
I have no problem with this fad if we keep passwords as a option. I can live with certs, but I also stopped using github already, even if I rarely used the pwd option at all.
Microsoft wants me to install their silly app. Already had it once, didn't like it and I don't trust their apps on my phone. I already hate when services profile my machine. I use many of those and at some point I already stopped using services because I didn't want to check my mail again...
Security theatre and other ambitions to the largest degree. I have no problem with that if you give me the option.
My passwords do work. Those of other people also work in most cases. There are sometimes these service accoutns which use 'batman' as a password. That is bad and lazy but also a solvable problem.
I would argue that password policies are bad too, aside mabye from length. Adding any other rule is silly and compromises security and accessibility in my opinion.
Passwords aren't that difficult if you have a system which works as a seed to calculate passwords for a service where a leak doesn't allow for conclusions in the other direction. Ok, not that easy, but manageable. You could use a std password and append the name of the service and in most cases that would suffice if your plaintext pwds don't leak.
I have no problem with this fad if we keep passwords as a option. I can live with certs, but I also stopped using github already, even if I rarely used the pwd option at all.
Microsoft wants me to install their silly app. Already had it once, didn't like it and I don't trust their apps on my phone. I already hate when services profile my machine. I use many of those and at some point I already stopped using services because I didn't want to check my mail again...
Security theatre and other ambitions to the largest degree. I have no problem with that if you give me the option.
My passwords do work. Those of other people also work in most cases. There are sometimes these service accoutns which use 'batman' as a password. That is bad and lazy but also a solvable problem.
I would argue that password policies are bad too, aside mabye from length. Adding any other rule is silly and compromises security and accessibility in my opinion.
This is just another step towards people having citizen passes (renamed covid health passes), and their entire identity will be stored on them, including their personal login to the internet, authorised by the tech mafia.
What they are doing is anti-freedom, anti-privacy, and anti-human in the end. The kind of future they want in the name of "security" will be dystopian.
What they are doing is anti-freedom, anti-privacy, and anti-human in the end. The kind of future they want in the name of "security" will be dystopian.
The more general model of "local password that unlocks a key" seems like better security at every turn, and something that's feasible to implement on any system. This leaves attackers with the same options they'd have with 2FA: Gain access to the device that produces/stores the key, or crack the crypto. There's no technical feasibility concern for implementing good security, there's just endless incentives for these big players to pretend it's hard without you handing over control
In terms of passwords, I just have them written down in a file that I print out in a desk drawer and keep a copy of in my email.
For anyone tempted to do likewise, this is extraordinarily bad advice.
A hardcopy of your passwords is fine. Preferably one you've written out by hand.
An unencrypted online file is an extraordiarily bad idea. This puts your secrets where they're readily accessed and exfiltrated.
My own preference runs toward passphrases (based on random word selection) for secrets I've got to remember, and very long random strings for anything else, managed in a password manager or encrypted file.
A hardcopy of your passwords is fine. Preferably one you've written out by hand.
An unencrypted online file is an extraordiarily bad idea. This puts your secrets where they're readily accessed and exfiltrated.
My own preference runs toward passphrases (based on random word selection) for secrets I've got to remember, and very long random strings for anything else, managed in a password manager or encrypted file.
Is anyone else out there technically literate but still very resistant to using password managers?
I just don’t trust that it’s not going to burn me badly when I get locked out of a single point of failure, which locks me out of my entire financial and online life.
I just don’t trust that it’s not going to burn me badly when I get locked out of a single point of failure, which locks me out of my entire financial and online life.
I think this is why is important to choose wisely. As someone who’s been using the same one for over 10 years this is not my biggest concern.
Agreed. For example: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=lastpass or https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=1password.
I do let chrome remember my passwords (and sync them), as that has high utility (and I'm already significantly trusting that google have their shit together when it comes to security.)
But that said I have two categories of passwords; sites that are relatively trivial (e.g. spotify, hackernews), and sites that are tied to my identity or finances (e.g. email, banking). There really aren't that many in the latter category, and it's manageable (with a bit of practice) to use a memory palace type technique to associate sites with a strong visual that turns into a phrase. For the former category, I have a fairly junky heuristic that gives each site a unique non-dictionary based password that's usually 15+ characters. If my chrome profile ever disappears (or isn't obtainable), I could recreate passwords that way.
I do let chrome remember my passwords (and sync them), as that has high utility (and I'm already significantly trusting that google have their shit together when it comes to security.)
But that said I have two categories of passwords; sites that are relatively trivial (e.g. spotify, hackernews), and sites that are tied to my identity or finances (e.g. email, banking). There really aren't that many in the latter category, and it's manageable (with a bit of practice) to use a memory palace type technique to associate sites with a strong visual that turns into a phrase. For the former category, I have a fairly junky heuristic that gives each site a unique non-dictionary based password that's usually 15+ characters. If my chrome profile ever disappears (or isn't obtainable), I could recreate passwords that way.
Yes, they also significantly increase your potential attack surface. To get into your e-mail, an attacker now has the option to find a vulnerability in your e-mail server or your password manager.
They're great for random websites but they should probably not be used for your most critical secrets.
They're great for random websites but they should probably not be used for your most critical secrets.
I am. I use a system where I have a complex master password that is memorized that I mix with a unique password that I write down. It's not a perfect system, but it protects me from the three main attack vectors: an online attacker using a dictionary attack, an online attacker who knows one password and is checking for repeated passwords, and an offline attacker looking for a written password.
The main disadvantage is that it doesn't protect against is if someone is focused on me specifically and has compromised multiple passwords and figures out the pattern. However, I've always been wary of password managers as a single point of failure. At the very least, I have concerns about how a password manager would function when I want to use a password at work that was created on my home computer. Currently, I can easily write down my unique password on a slip of paper, and even if someone finds it they wouldn't be able to successfully use it.
The main disadvantage is that it doesn't protect against is if someone is focused on me specifically and has compromised multiple passwords and figures out the pattern. However, I've always been wary of password managers as a single point of failure. At the very least, I have concerns about how a password manager would function when I want to use a password at work that was created on my home computer. Currently, I can easily write down my unique password on a slip of paper, and even if someone finds it they wouldn't be able to successfully use it.
I use a similar approach where I have a master password combined with characters I derive using a simple algorithm from the name of the company or website.
A problem I run into is when I get forced to reset it and cannot reuse it.
A problem I run into is when I get forced to reset it and cannot reuse it.
I use my own password manager which uses encryption methods and file integrity measures that I've carefully refined over the past 20+ years. It allows me to recover individual password entries even if a password file has been heavily corrupted and makes automatic backups every time a new entry is stored.
Since it is a single point of entry and password managers are the #1 target of attack, I only use it for less important sites, though. I deal with user account access, encrypted disk images, and access to online banking separately by memorizing passphrases.
So in a nutshell I agree. If I'd use a 3rd party password manager, then only one that is open source and whose source code I have inspected, and in the amount of time this takes I could write my own anyway.
Since it is a single point of entry and password managers are the #1 target of attack, I only use it for less important sites, though. I deal with user account access, encrypted disk images, and access to online banking separately by memorizing passphrases.
So in a nutshell I agree. If I'd use a 3rd party password manager, then only one that is open source and whose source code I have inspected, and in the amount of time this takes I could write my own anyway.
I'd argue the worst thing in Microsoft's password policy engine was "complexity" rules instead of any way for allowing entropy rules.
A combo of "is this high enough entropy" and "is this in a rainbow table already" would let people have personal and memorable pass phrases.
- Microsoft's own experience[1] realized length beats the "one of each kind of symbol" nonsense some time ago: https://docs.microsoft.com/en-us/archive/blogs/msftcam/passw...
- Simple entropy checker: https://www.bee-man.us/computer/password_strength.html
- Keepass tries a few other angles as well: https://keepass.info/help/kb/pw_quality_est.html
- Overview of Diceware for hand generating pass 'phrases': https://theintercept.com/2015/03/26/passphrases-can-memorize...
---
1. TL;DR quote from TechNet:
- Password lengths are significantly more important than password complexity requirements
- Password complexity only prevents users from creating easy-to-guess passwords
- Password complexity actually reduces the total number of possible passwords in a key-space
- In theory, the most secure password policy would define a longer-length password with no other complexity requirements with a very large dictionary that consists of all easily-guessable passwords
A combo of "is this high enough entropy" and "is this in a rainbow table already" would let people have personal and memorable pass phrases.
- Microsoft's own experience[1] realized length beats the "one of each kind of symbol" nonsense some time ago: https://docs.microsoft.com/en-us/archive/blogs/msftcam/passw...
- Simple entropy checker: https://www.bee-man.us/computer/password_strength.html
- Keepass tries a few other angles as well: https://keepass.info/help/kb/pw_quality_est.html
- Overview of Diceware for hand generating pass 'phrases': https://theintercept.com/2015/03/26/passphrases-can-memorize...
---
1. TL;DR quote from TechNet:
- Password lengths are significantly more important than password complexity requirements
- Password complexity only prevents users from creating easy-to-guess passwords
- Password complexity actually reduces the total number of possible passwords in a key-space
- In theory, the most secure password policy would define a longer-length password with no other complexity requirements with a very large dictionary that consists of all easily-guessable passwords
The problem is how do you computer entropy? In my opinion, the only truly effective way is to generate passwords using a fixed procedure like diceware or by throwing password cracking software at a potential password and seeing how long it takes to discovery.
IMHO passwords always had been broken from the get to go for general purpose usage.
This doesn't mean bad password rules haven't made it worse.
Neither doesn't it mean there are special purpose use-case where passwords can make sense, like for a a way to unlock whatever you use to eliminate passwords.
But even then there are always better alternatives, like word pins.
In my opinion there are a few services which should have a high level of security, like e.g. email. In which case I would argue a password is not enough and should be complemented with a hardware token or similar which prevents certain kinds of fishing attacks passwords (or word pins) are prone too.
Some have a security level where a password, word pin or HST+PIN would be ok.
But many more are partially irrelevant logins which are best of with a password manager, HST without PIN, SSO, or similar which all can (but often/mostly isn't) done in a reasonable privacy aware way.
> Passwords Put You In Control
How, do you have more control?
Any data sharing can be done and promoted even without SSO or similar.
You still login with email or worse phone number, which (in general) gives much more information away then any HSK.
And let's be honest I try to avoid making accounts if possible/reasonable but still accumulated ~70 logins. How am I supposed to remember more then a small number (let's say 10) secure passwords which must not have any pattern or there is a risk if a site is corrupted.
That wasn't ever a option, never feasible and always broken.
It doesn't put you into control, it forces you to use "something" to give control to (a notepad, password manager etc.).
So IMHO if we want an improvement we need some form of privacy preserving, open anti-decentralizing "SSO"-like protocol/system which can be feed by HST, Secure Modules or simple Apps.
Does it exists? Probably, somewhat? But making it widely used seems as unlikely as people (in general) choosing passwords if they have the choice to not have passwords.
This doesn't mean bad password rules haven't made it worse.
Neither doesn't it mean there are special purpose use-case where passwords can make sense, like for a a way to unlock whatever you use to eliminate passwords.
But even then there are always better alternatives, like word pins.
In my opinion there are a few services which should have a high level of security, like e.g. email. In which case I would argue a password is not enough and should be complemented with a hardware token or similar which prevents certain kinds of fishing attacks passwords (or word pins) are prone too.
Some have a security level where a password, word pin or HST+PIN would be ok.
But many more are partially irrelevant logins which are best of with a password manager, HST without PIN, SSO, or similar which all can (but often/mostly isn't) done in a reasonable privacy aware way.
> Passwords Put You In Control
How, do you have more control?
Any data sharing can be done and promoted even without SSO or similar.
You still login with email or worse phone number, which (in general) gives much more information away then any HSK.
And let's be honest I try to avoid making accounts if possible/reasonable but still accumulated ~70 logins. How am I supposed to remember more then a small number (let's say 10) secure passwords which must not have any pattern or there is a risk if a site is corrupted.
That wasn't ever a option, never feasible and always broken.
It doesn't put you into control, it forces you to use "something" to give control to (a notepad, password manager etc.).
So IMHO if we want an improvement we need some form of privacy preserving, open anti-decentralizing "SSO"-like protocol/system which can be feed by HST, Secure Modules or simple Apps.
Does it exists? Probably, somewhat? But making it widely used seems as unlikely as people (in general) choosing passwords if they have the choice to not have passwords.
OP opines with retrospect. I'm a dyed in the wool Linux bod but I can't accuse MS of destroying passwords via AD.
AD is simply a hierarchical database of data that is DNS federated. It has a heavy lean to windward in the guise of Kerberos and LDAP. The thing about Kerb is DNS ... lol!
Our internets needed RFC1918 to squeeze a few extra decades out of a 32 bit IPv4 address. We have NAT and that means that DNS becomes difficult for identity purposes. That means that Kerberos doesn't work quite as well as originally envisaged, without some bodges. That means that you use a lot of NTLM ...
Unixs and Apples have also always relied on passwords as a first authentication method.
OK, I hate the term "best practice". There is no such thing, and MS deploys that term with complete and utter gay abandon. That is what is wrong for me. I think there is good and bad practice but never "best". There is no discussion outside of their own little minds in much of the MS documentation. I suspect this is changing right now but I have read an awful lot of MS docs over around four decades.
Authentication is hard. Trust is harder. Twatting around with phrases like "passwords are wrong" is irresponsible. You need to look at the whole chain of trust and how to authenticate it sensibly.
AD is simply a hierarchical database of data that is DNS federated. It has a heavy lean to windward in the guise of Kerberos and LDAP. The thing about Kerb is DNS ... lol!
Our internets needed RFC1918 to squeeze a few extra decades out of a 32 bit IPv4 address. We have NAT and that means that DNS becomes difficult for identity purposes. That means that Kerberos doesn't work quite as well as originally envisaged, without some bodges. That means that you use a lot of NTLM ...
Unixs and Apples have also always relied on passwords as a first authentication method.
OK, I hate the term "best practice". There is no such thing, and MS deploys that term with complete and utter gay abandon. That is what is wrong for me. I think there is good and bad practice but never "best". There is no discussion outside of their own little minds in much of the MS documentation. I suspect this is changing right now but I have read an awful lot of MS docs over around four decades.
Authentication is hard. Trust is harder. Twatting around with phrases like "passwords are wrong" is irresponsible. You need to look at the whole chain of trust and how to authenticate it sensibly.
> Unixs and Apples have also always relied on passwords as a first authentication method.
Nowhere have I seen anyone primarily relying on passwords (unless they didn’t have a clue.) Everyone is using PKI.
Nowhere have I seen anyone primarily relying on passwords (unless they didn’t have a clue.) Everyone is using PKI.
I don't understand the mental leap here to blame password rotation on Microsoft specifically. Shouldn't that blame be aimed at (older) NIST and (current) PCI DSS compliance? Blaming Microsoft for making it easy for sysadmins to centrally control a password policy through Active Directory seems, to me, just... very misguided.
Microsoft has made a big deal out of this being their way forward, but the only way to logon to a Windows Server is to use a password (unless you count a Smartcard) and their answer for how this all fits together is pretty much "let's just talk about our cloud services". I don't think this aim is going to reach the majority of organisations any time soon.
I wish they’d come out and say that Windows Server is just going to be tracking kernel/plumbing changes from the mainstream release and no new features are planned. The biggest “feature” in Server 2022 is that you can now address more cores and RAM (2048 cores and 48TB) because apparently SQL Server needed that.
I see every day someone coming onto r/sysadmin saying “oh I have this SBS 2011 server that really needs an update” and all these graybeard Windows admins come out of the woodwork screaming about how they need to set up a old school AD domain controller and print server and all this crap. It’s dead guys. New apps should not be adopting Windows Server.
I see every day someone coming onto r/sysadmin saying “oh I have this SBS 2011 server that really needs an update” and all these graybeard Windows admins come out of the woodwork screaming about how they need to set up a old school AD domain controller and print server and all this crap. It’s dead guys. New apps should not be adopting Windows Server.
Yes it's been an interesting one to read through Microsoft's "what's new" for Windows 2022, there's multiple references to TPM support and Credential Guard and the MS Edge Browser (features we have already). We then have Azure Only features, and "Azure Hybrid" features.
Microsoft have effectively done what you describe with Exchange. Current literature is pretty open about the fact they are barely working on the on-premises version. Which would be fine if they sorted out the hybrid management situation.
Microsoft have effectively done what you describe with Exchange. Current literature is pretty open about the fact they are barely working on the on-premises version. Which would be fine if they sorted out the hybrid management situation.
You can also store the certificate on a Yubikey instead of a smart card. We do that at my work in combination with an associated pin so that you have two factors.
It erks me how the author has described that Microsoft RUINED passwords. Sorry, but AD has been around for decades and implemented passwords way before we had the technology or foresight of today to know and do better.
You can't say a company ruined something when that was arguably the best implementation of that at the time. It's like saying Ford ruined cars because they produced the first combustion engine and now that we all use electric cars they ruined the automobile and enabled decades of emissions in hindsight.
I've reviewed the AD password policies for around 80+ companies now and I can safely say that many of those companies were not even implementing the full extent of what the policy would allow.
I'm not disagreeing with the premise of passwords, just that it's easy to stand on a pedestal decades later in hindsight and say "they did it badly" knowing what we know now.
You can't say a company ruined something when that was arguably the best implementation of that at the time. It's like saying Ford ruined cars because they produced the first combustion engine and now that we all use electric cars they ruined the automobile and enabled decades of emissions in hindsight.
I've reviewed the AD password policies for around 80+ companies now and I can safely say that many of those companies were not even implementing the full extent of what the policy would allow.
I'm not disagreeing with the premise of passwords, just that it's easy to stand on a pedestal decades later in hindsight and say "they did it badly" knowing what we know now.
>>In the name of security and convenience your computer will be less and less your own.
In whatever they name it, the obvious attitude of these tech giants has nearly always been that it is not MY/OUR computer, but THEIR COMPUTER.
Just the attitude that they could reboot anytime to force an update, nevermind what was happening at the time, whether we were in a critical presentation or other situation. It seems it took a Windows computer literally rebooting in the midst of a surgery and endangering the patient's life to start "allowing" us plebs to partially postpone and schedule updates.
(And yes, I get it that there are millions of DEUs out there who will fail to update in a timely fashion and endanger us all by being ignorant botnet hosts. That does NOT mean that the first response should be to stomp on everyone)
Toxic attitude.
In whatever they name it, the obvious attitude of these tech giants has nearly always been that it is not MY/OUR computer, but THEIR COMPUTER.
Just the attitude that they could reboot anytime to force an update, nevermind what was happening at the time, whether we were in a critical presentation or other situation. It seems it took a Windows computer literally rebooting in the midst of a surgery and endangering the patient's life to start "allowing" us plebs to partially postpone and schedule updates.
(And yes, I get it that there are millions of DEUs out there who will fail to update in a timely fashion and endanger us all by being ignorant botnet hosts. That does NOT mean that the first response should be to stomp on everyone)
Toxic attitude.
Windows Update was practically malware at the start of Windows 10's life. I don't miss those days.
Headlines like this give me a knot in my stomach and make me really anxious. How long until my working solution no longer works thanks to the masses of tech-illiterate animals without password managers? Or should I be more upset that I, a free man, should be forced to manage passwords?
There are two issues here:
1. Unified and standardized password management must become a thing
2. Fewer sites should require a permanent account to make a transaction
There are two issues here:
1. Unified and standardized password management must become a thing
2. Fewer sites should require a permanent account to make a transaction
passwords ain't broken but the thinking here is at HN :(
passwords are going to be around for a good long time as i suspect WebAuthn and others will discover. the author is correct that hackers are smarter than companies and developers about human psychology, which, like, matters. databases want identity data and a simple 2FA on top of passwords is winning because marketing can get your phone # too. and on and on...
If I was Apple, I would spin off FaceID as a separate business. It is proven at scale, can be packed into tiny device and no worse than passwords. It is beyond me that I still have to carry rectangular cards to buy something or have little book to get through Airport or type password to login anywhere.
Apple is working on getting state ID cards in your phone and supposedly even the airport TSA will accept them. https://www.apple.com/newsroom/2021/09/apple-announces-first...
As much as I'm a fan of gratuitous Microsoft bashing, this would be a far better essay without the distracting and counterfactual swipes.
Yes, AD does implement a number of previously recommended password management practices, and site administrators can choose to impose these.
No, Microsoft did not come up with those policies.
As I replied to Kyle on Mastodon, my copy of the late Evi Nemeth's UNIX System Administration Handbook 2nd ed, (1995) has a discussion of password aging (automated timed-out passwords) on pages 95 & 544. She's not a fan, but the capabilitiy exists and is noted on Solaris, Irix, and BSDI. She does recommend rotating the root password regularly.
https://toot.cat/@dredmorbius/106965632066772456 (thread)
Note that at the time, Microsoft produced largely only single-user operating systems, without any user password at all. (Yes, Windows NT 3.1 was released in 1993. It saw very little use. Active Directory wasn't released until 1999.)
What AD ended up impelemnting was in fact considered best practices at the time. And implementing best practices as standard (and default) configurations is a powerful tool for compliance. As has been demonstrated many times, and curren global events show again, leaving choice to end-users tends to result in very poor safety pratices with severe consequences for all. Unforunatly, knowledge evolves, whilst encoded practices often don't.
Kyle's principle gripe is that Microsoft (and Apple, Amazon, and Google, at the very least) are all racing down the same road as fast as they can of ensuring that their devices form the core of digital identity management. Yes, I'd argue that that is a significant concern.
But better advocacy without needless distractions would help.
Yes, AD does implement a number of previously recommended password management practices, and site administrators can choose to impose these.
No, Microsoft did not come up with those policies.
As I replied to Kyle on Mastodon, my copy of the late Evi Nemeth's UNIX System Administration Handbook 2nd ed, (1995) has a discussion of password aging (automated timed-out passwords) on pages 95 & 544. She's not a fan, but the capabilitiy exists and is noted on Solaris, Irix, and BSDI. She does recommend rotating the root password regularly.
https://toot.cat/@dredmorbius/106965632066772456 (thread)
Note that at the time, Microsoft produced largely only single-user operating systems, without any user password at all. (Yes, Windows NT 3.1 was released in 1993. It saw very little use. Active Directory wasn't released until 1999.)
What AD ended up impelemnting was in fact considered best practices at the time. And implementing best practices as standard (and default) configurations is a powerful tool for compliance. As has been demonstrated many times, and curren global events show again, leaving choice to end-users tends to result in very poor safety pratices with severe consequences for all. Unforunatly, knowledge evolves, whilst encoded practices often don't.
Kyle's principle gripe is that Microsoft (and Apple, Amazon, and Google, at the very least) are all racing down the same road as fast as they can of ensuring that their devices form the core of digital identity management. Yes, I'd argue that that is a significant concern.
But better advocacy without needless distractions would help.
Obligatory XKCD Horse Battery Stapler reference.
https://xkcd.com/936/
MS AD and many others certainly did a lot to prevent this sane password future.
- arbitrary and low max password lengths
- weak unsalted hashes
- mandatory short rotation (never mind your passphrase has 50 bits of entropy and cracking it from hash with state of the art would still take years)
- banning whitespace
- requiring symbols and numbers and capital letters
- instead of estimating entropy
https://xkcd.com/936/
MS AD and many others certainly did a lot to prevent this sane password future.
- arbitrary and low max password lengths
- weak unsalted hashes
- mandatory short rotation (never mind your passphrase has 50 bits of entropy and cracking it from hash with state of the art would still take years)
- banning whitespace
- requiring symbols and numbers and capital letters
- instead of estimating entropy
This claim from the article is not really true:
"This passwordless future requires that Microsoft follow in Apple’s and Google’s footsteps in deciding which software you are allowed to run on your computer."
For example on Windows the "passwordless future" simply means that you don't need to type in your password during the authentication (for example when you login). You can still continue run all the same apps you have been running before.
"This passwordless future requires that Microsoft follow in Apple’s and Google’s footsteps in deciding which software you are allowed to run on your computer."
For example on Windows the "passwordless future" simply means that you don't need to type in your password during the authentication (for example when you login). You can still continue run all the same apps you have been running before.
One thing that is really holding back a “passwordless” future is that no large companies are offering a password manager. No one does, or really should, trust the tiny companies that do password managers today. If say LastPass had a major breach, they could just fold the company and it wouldn’t be an enormous loss, compare to a Google that can’t fold. In fact, it might be more profitable for LastPass to sell all the passwords and credit cards it has access to then continue to earn $2 a year from a handful of people. People intuit this and are very hesitant to trust all their passwords to LastPass or OnePass or whatever.
The browser password managers aren’t full featured enough. They don’t remember history well, it’s hard to add and edit entries, and it’s especially hard to use them outside that browser or on sites where the prompts don’t trigger right (still very common.)
The browser password managers aren’t full featured enough. They don’t remember history well, it’s hard to add and edit entries, and it’s especially hard to use them outside that browser or on sites where the prompts don’t trigger right (still very common.)
Apple offers Keychain and I think it could be argued that Apple is one of the biggest corporations to ever exist.
This strikes me as being part of the larger war on general purpose computing. Microsoft is saying that, in order to use your expensive device, you need another expensive device, and you need to involve a third party as an arbiter.
See Cory Doctorow's excellent 2011 keynote to the 28th Chaos Computer Club conference entitled "The Coming War on General Purpose Computing": https://boingboing.net/2011/12/27/the-coming-war-on-general-...
What do we do about this? I can (and do) run open-source software on my laptop, but what about my parents, kids, friends, et al? Some of them care, but can't be bothered. Others are oblivious.
See Cory Doctorow's excellent 2011 keynote to the 28th Chaos Computer Club conference entitled "The Coming War on General Purpose Computing": https://boingboing.net/2011/12/27/the-coming-war-on-general-...
What do we do about this? I can (and do) run open-source software on my laptop, but what about my parents, kids, friends, et al? Some of them care, but can't be bothered. Others are oblivious.
> What do we do about this?
Have a look at the website where the OP is published.
Have a look at the website where the OP is published.
Can anyone speak to merits/demerits of purism products? A security focused linux laptop is honestly quite appealing to me, although I think preinstalled openbsd would be even better. Would ideally like some sort of secure boot as well.
So, what this all boils down too, is centralization of weakness?
As in, all people, store all there "passwords" in one centralized hierarchical structure, easily accessible by a weak traditional "password" or at least 2factor and that is supposed to be saver?
Let me guess, the next step is a AI that predicts likelihood of you being you, by access and usage behaviour patterns? Locking you out, if your late for work? etc. Let Co-Workers vouch for a transaction being in character? Sure, he would buy three cars.. Last step, is location data being necessary to login- the device has to be in the sphere of trust around your cellphone.
At that point the full fledged rebellion will have reached the developer offices, ending this nightmare in fire, as the mob sides with mob for protection against the security insanity.
As in, all people, store all there "passwords" in one centralized hierarchical structure, easily accessible by a weak traditional "password" or at least 2factor and that is supposed to be saver?
Let me guess, the next step is a AI that predicts likelihood of you being you, by access and usage behaviour patterns? Locking you out, if your late for work? etc. Let Co-Workers vouch for a transaction being in character? Sure, he would buy three cars.. Last step, is location data being necessary to login- the device has to be in the sphere of trust around your cellphone.
At that point the full fledged rebellion will have reached the developer offices, ending this nightmare in fire, as the mob sides with mob for protection against the security insanity.
Good article. I used to love reading Kyle Rankin’s rantings in Linux Journal… good times.
I built my own hardware password manager years ago and it works great for me. It is based on a small microprocessor (PIC) that emulates a keyboard via USB and has a small LCD display and 3 buttons. You simply scroll through the menu that lists the name of the thing you are logging into, it does not display the password, you press the button and it enters the password via keyboard USB HID. Works on any OS any device that uses USB keyboard which is basically everything.
Pretty simple, tough to hack, no way to get into it except me (no remote access to it, you have to know how to program it). Bad thing is if I ever lose it I am screwed and would have to change every password, because I don't have any authorization on it, whoever possesses it can plug it in and hit a button and it will dutifully output the passwords. I originally made it because for work I probably type in the same password 50 times a day, with this I just plug it in scroll to the work password and then its just 1 button push each time. Someday I may think of a way of securing it somehow, but for now I just have to make sure I don't lose it!
I have a teensy sitting in a box somewhere waiting for me to build exactly something like this! Care to share your build process?
Regarding initial security - have you though about a button sequence with the 3 buttons after it's plugged in, which 'unlocks' the password list?
Regarding initial security - have you though about a button sequence with the 3 buttons after it's plugged in, which 'unlocks' the password list?
hehe ya, i should put it up on my github, you are getting me interested again.
For authentication ya, button sequence, or another thing i was thinking might be cool would be NFC. I have a little NFC chip, could make a new version. That would be cool then you could activate it with your phone using an NFC app.
For authentication ya, button sequence, or another thing i was thinking might be cool would be NFC. I have a little NFC chip, could make a new version. That would be cool then you could activate it with your phone using an NFC app.
This is sadly all true. Password policies like "you must/must not use this characters" are bad and the worst are "you must change this password every six weeks". The first is a restriction which prevents well memorable passwords, the seconds enforce throwing away a good password for another on. So users do what? The look for a pattern to pass this test, a acceptable solution is a famous german football club "Schalke04" or use the month "June_06".
The enforced changing passwords was never a good thing. At least the german language differs between a password (Passwort) which is assigned to one person and parole (Kennwort) which is common for all allowed persons. And yes, Windows still ask for a parole like Win98.
The last known users of parole where the soldiers of the ancient roman empire. It was required to change it rapidly, because some Gaul oder Germanic could have beaten it out of a soldier. The IT applies security measures from the ancient Romans! A password instead must match 'you' and only you can use it, the guard must know you (e.g. passport) and you need to know the personal password and it doesn't allow for bringing others into the camp.
Well. A nowadays some people recommend passwords with the length of an SSH-Key because "Computer getting faster". Seriously - NO! It the computers job to lock your account for some time and making a computer based attack useless. Linux is doing that on your TTY with a few seconds and GNOME is temporarily banning you for 10 minutes. Even an iPhone does this. And yes, one long and well memorable password which is not easily guessable is fine. By the way, SSH-Keys are a fine and good thing for automatic authentication.
And Microsoft has a shameful history, so called "Security Questions" which are often enforced. What is the family name of your mom? Your favorite meal? The name of your pet? What is wrong with Microsoft. It not a security question, it is a wide open backdoor. And now TPM? The correction description of TPM is "We don't trust you, you must trust us". Well, trust is a mutual thing?
The enforced changing passwords was never a good thing. At least the german language differs between a password (Passwort) which is assigned to one person and parole (Kennwort) which is common for all allowed persons. And yes, Windows still ask for a parole like Win98.
The last known users of parole where the soldiers of the ancient roman empire. It was required to change it rapidly, because some Gaul oder Germanic could have beaten it out of a soldier. The IT applies security measures from the ancient Romans! A password instead must match 'you' and only you can use it, the guard must know you (e.g. passport) and you need to know the personal password and it doesn't allow for bringing others into the camp.
Well. A nowadays some people recommend passwords with the length of an SSH-Key because "Computer getting faster". Seriously - NO! It the computers job to lock your account for some time and making a computer based attack useless. Linux is doing that on your TTY with a few seconds and GNOME is temporarily banning you for 10 minutes. Even an iPhone does this. And yes, one long and well memorable password which is not easily guessable is fine. By the way, SSH-Keys are a fine and good thing for automatic authentication.
And Microsoft has a shameful history, so called "Security Questions" which are often enforced. What is the family name of your mom? Your favorite meal? The name of your pet? What is wrong with Microsoft. It not a security question, it is a wide open backdoor. And now TPM? The correction description of TPM is "We don't trust you, you must trust us". Well, trust is a mutual thing?
To add to that, MS Active Directory hashes are very weak. One round of MD4. Very easy to crack.
o Passwords ARE fundamentally broken and they do not put you in control. Passwords must be shared to work, therefore they can never truly be secret. Only a private/public key pair can even hope to authenticate an entity.
o Surveillance is present in all neighborhoods. The realm of free software is home to surveillance by the network, and attacks on the software ranging from distribution to zero days to common misconfigurations.
To top it off, the author perpetuates an anti-pattern, which is to place faith in the idea of password policies at all. NIST has recognized the pointlessness of password policies and now simply recommend that passwords are compared against databases of known passwords.
Fortunately we don't need to wonder what to do. WebAuthN is here now and has been ready for a couple years now.