Microsoft ruined passwords, now aims for a passwordless future
puri.sm
puri.sm
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.)
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.
...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.
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.
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".
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'.)
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.
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.
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 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.
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.
Nope. Not the case. I'm pretty sure I log into my password manager with.... a password.
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.
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.
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.
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...
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]
[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.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.
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).
Two years of misery and stubbornness. One hidden menu option.
[1]: https://account.activedirectory.windowsazure.com/proofup.asp...
That's...slightly better, I guess. I still want passwords though as the base level.
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).
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.
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.
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.
What's weird is that Teams on Linux does show the "sign in with security key" but it doesn't do anything.
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.
People have option to use codes.
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.
Passwords are broken, now give us your face for facial recognition. Facial recognition is broken, now etc etc
It's not even that hard to avoid Microsoft.
>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.
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, 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.
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...
Please, explain to me how an arbitrary number of RPs can collude to link a FIDO2 identity.
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 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!
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.
See https://github.blog/2017-07-20-soft-u2f/ for an example.
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.
This is (AFAICT) intended to be used by, say, an enterprise who wants to restrict their employees to some trusted brand, but some banks and similar have also used it.
This is somewhat discouraged and annoying. In general, most places you can use a "self-signed" authenticator, which could be software and nobody would know.
What you're describing is only today's present conditions. They're allowed to continue because adoption is low, and so businesses aren't trying to add even more "security". This is like IP before DPI, or when people considered Bitcoin anonymous.
Once FIDO keys become popular, and especially if software-only keys become popular, companies will most certainly restrict their services to only work with trusted brands.
It’s a risk, and I believe the batch attestation was controversial as a result. But the use cases are compelling.
Think forward to when most everyone is using security keys, and 90% of users use one from one of the big brands. Then someone tells a bank's security chief "did you know users can defeat our security by installing a piece of software?"
They'll look for a solution to that, and the solution will be using the feature to restrict keys to trusted brands. The only downside will be annoying a small segment of customers. But at that point they won't care, because those customers don't conform to their security mold anyway.
For a contemporary situation playing out right now, many websites have decided to outright block or CAPTCHA-harass connections from datacenter IP addresses. In their mind, all such connections are fraud and abuse rather than legitimate paying customers that happen to have custom network setups.
And of course the use cases seem compelling in the corporate context, because corporations are authoritarian organizations where top-down control is simply accepted. The problem is that they push their authoritarian desire for control into technical standards, which then unleash that centralizing control onto the outside world.
They obviously exist within a larger society where workers are free to quit, have some rights that can't be taken away, are bound by agreements, etc. But the organizational structure itself is strictly hierarchical.
The problem comes when these assumptions are baked into systems that are supposed to serve wider society. A corporation can tell their employees that they must use only certain computers to do their work, modify those devices, revoke access on a whim, etc. Whereas in wider society, relationships should be that of independent peers interacting through well-defined protocols, with each party free to make their own choices.
In that broader context, I’m surprised that so many folks in this thread are arguing, essentially, that companies have a strong incentive to push (potentially needless, or costly from a privacy-perspective[1]) features on their users.
Historically, my feeling—-and I think that of many in the security industry—-was that the market does not reward pushing security, especially not security that customers can’t see; as a result, there’s some chunk of security theater, but real security features are often under-rewarded.
shrug
[1] To be clear, I disagree that most of these things have a severe privacy cost, hence my point that FIDO allows strong pseudonymity.
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.
I would argue you _are_ compromising. You're accepting the drawbacks of passwords in exchange for not having to use any of the alternatives.
Genuinely curious.
:-)
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.
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.
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
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.
This is pure gold.
I know this is a lost discussion, but it is technically correct. End of comment.
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).
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).
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.
Biometric data not getting as much legal protection as a password can also cause issues.
Except I distinctly remember unlocking an iphone with a piece of sellotape a few years ago.
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?
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.
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.
Diceware passwords are actually a great example of passwords that are truly random and unmemorable, yet can be memorized easily
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 don't know if WebAuthN is the answer either. I just know that passwords are broken.
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.
"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.
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.
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.
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.
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!"
No, obviously not. They have a dominating market share and I have no choice.
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.
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.
Most vaults support offline storage.
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.
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.
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 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...
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.
- It should be known only by you and
- it should be easy to change in case it is compromised.
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.
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?
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.
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.
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?
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.
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.
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.
`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.
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.
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?
> 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.
Is it? What's special about computer chips vs. id cards?
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.
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?
> 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.
If this idea gains traction then Microsoft will roll over the objections of those who can't/won't use it, and tough luck.
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...
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.
That's not entirely true, as demonstrated by constructions like PAKE. It is a shame, though, that the adoption is almost nonexistent.
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.
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!
The navy is not a decentralized organization. Distribution of the results is not a concern.
Unintentionally ...
This is in 1747: https://www.bbc.co.uk/news/uk-england-37320399
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?
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?
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?)
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.
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 mybackupemail@gmail.com 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.
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)
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.
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.
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.
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).
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?
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...
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.
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.
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.
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 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.
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 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
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.
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.":
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.
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.
Seriously, deprecate SMS already. I deprecated it 10 years ago.
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.
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.
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.
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.
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.
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.
Thanks for raising this point though. Lack of copy-ability is more an implementation issue than a problem with the standard.
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 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.
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.
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)."
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.
There’s also the password reuse problem, though better policies might discourage reuse, it’ll still happen.
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 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.
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.
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.
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.
Yeah. In fact, I'd wager that longer password lengths make reuse even more common if people aren't using password managers.
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.
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.
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.
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)
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...
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.
Disable secure boot and disable integrity checks with bcdedit?
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.
Nowhere have I seen anyone primarily relying on passwords (unless they didn’t have a clue.) Everyone is using PKI.
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
Regarding initial security - have you though about a button sequence with the 3 buttons after it's plugged in, which 'unlocks' the password list?
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.
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.
Holy hell this hit hard.
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."
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 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.
They're great for random websites but they should probably not be used for your most critical secrets.
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.
A problem I run into is when I get forced to reset it and cannot reuse it.
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.
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.
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.
Have a look at the website where the OP is published.
"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.
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.
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.
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.
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.)
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.
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?
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.
I do not want to lose my phone and lose access to my computer as well...
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
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
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.