[HN Gopher] Microsoft ruined passwords, now aims for a passwordl...
___________________________________________________________________
Microsoft ruined passwords, now aims for a passwordless future
Author : summm
Score : 94 points
Date : 2021-09-20 20:55 UTC (2 hours ago)
(HTM) web link (puri.sm)
(TXT) w3m dump (puri.sm)
| echelon wrote:
| 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.
| hammyhavoc wrote:
| A forbidden thought.
| citrusynapse wrote:
| "Remember to buy our official chargers. Here are some ads from
| third party sponsors."
|
| Holy hell this hit hard.
| userbinator wrote:
| Exactly. The authoritarian "security" industry is largely to
| blame for helping to build this dystopia of corporate control.
| rrobukef wrote:
| 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.
| autoliteInline wrote:
| 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.
| dathinab wrote:
| 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.
| gerdesj wrote:
| 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.
| mastrsushi wrote:
| On Windows being a nursing home.
|
| I found desktop Linux to be more like nursery school. Windows is
| when it's time to put the toys away.
| hammyhavoc wrote:
| I found Linux to be a workshop of tools for work and science.
| Nothing "nursery school" about that.
| autoliteInline wrote:
| It isn't like Windows is a toy I admit.
|
| My view is that it's the result of decades worth of customer
| demands (scarcely any of which I need) and a tendency to
| feature creep to do major releases. The cruft in a thing like
| that is remarkable.
| Spooky23 wrote:
| 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.
| initplus wrote:
| 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.
| Spooky23 wrote:
| 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.
| mc32 wrote:
| 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.
| Spooky23 wrote:
| 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.
| mjg59 wrote:
| > "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.
| webmobdev wrote:
| 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).
| hughrr wrote:
| I want my passwords back. Windows hello doesn't know who the hell
| I am until after lunch.
| hammyhavoc wrote:
| It knew who you were _before_ lunch?
| coolspot wrote:
| Lunch can alter people's faces. Facts.
| lom wrote:
| 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...
| megaman821 wrote:
| The app can be configured to require a PIN/fingerprint to
| authenticate you. The 2 factors become control of the phone and
| your fingerprint.
| brendoelfrendo wrote:
| 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.
| llampx wrote:
| If you have a fingerprint or can hack it, it basically will
| let you into the phone and into the auth app.
| marcodiego wrote:
| 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.
|
| Fingerprints fails both requirements. They may be good
| identifiers, but are terrible passwords.
| mattashii wrote:
| Yep. But no-one ever leaves their fingerprints on their
| phone, so this is 100% safe. /s
| marcodiego wrote:
| 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.
| mattashii wrote:
| 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.
| marcodiego wrote:
| 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...
| mattashii wrote:
| > 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.
| lom wrote:
| 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.
| Spooky23 wrote:
| 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?
| rastafang wrote:
| embrace... "extinguish", etc
| bdamm wrote:
| The author's conclusions are naive on a couple of fronts:
|
| 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.
| michaelt wrote:
| _> 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-dub wrote:
| > 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?
| tehbeard wrote:
| Nope. Left as an exercise for the user and 2FA provider,
| and/or the service to provide an alternate recovery system.
| a-dub wrote:
| 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?)
| aseipp wrote:
| 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
| aseipp@foo.com (the music website) you stole from me, you
| couldn't use it for aseipp@bar.com (my bank account).
| aseipp wrote:
| 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 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.
| a-dub wrote:
| 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)
| aseipp wrote:
| 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.
| a-dub wrote:
| > 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.
| megous wrote:
| And how do you protect your secret keys, if passwords are
| fundamentally broken?
| NieDzejkob wrote:
| > 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.
| acdha wrote:
| 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.
| thaumasiotes wrote:
| 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.
| gerdesj wrote:
| 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!
| JoshTriplett wrote:
| > 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.
| gerdesj wrote:
| "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?
| WorldMaker wrote:
| > 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.)
| recursive wrote:
| 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.
| jareklupinski wrote:
| 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.
| Dylan16807 wrote:
| > 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'.)
| WorldMaker wrote:
| 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).
| Dylan16807 wrote:
| 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.
| Aerroon wrote:
| > _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.
| WorldMaker wrote:
| 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 than appreciating that passwords
| need to go and we should be working 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.
| forty wrote:
| 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)
| WorldMaker wrote:
| 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.)
| softwarebeware wrote:
| > 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
| cptskippy wrote:
| > 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.
| popotamonga wrote:
| Offline password manager. Keepass. Downside is it's up to you
| to not lose the data.
| unethical_ban wrote:
| That's why you still use a decently long passphrase and use
| an offline password manager.
| Dylan16807 wrote:
| 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.
| WorldMaker wrote:
| 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_.
| debaserab2 wrote:
| 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).
| mahathu wrote:
| Bitwarden is really good for this also. I had the same
| concerns before I started using it! Works great on mobile too
| travoc wrote:
| 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.
| amachefe wrote:
| Firefox has the same feature, i have been more firefox user
| since Chrome was hanging my system sometime ago
| jonny_eh wrote:
| 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.
| WorldMaker wrote:
| 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".
| Dylan16807 wrote:
| 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.
| Waterluvian wrote:
| 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.
| advael wrote:
| 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
| Ajedi32 wrote:
| > 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
| UncleMeat wrote:
| > 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.
| alerighi wrote:
| > 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.
| _carbyau_ wrote:
| The trick is having a password manager and associated
| password database synchronised across your
| linux/windows/android/iOS/MacOS devices.
| rrobukef wrote:
| 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)...
| djrogers wrote:
| You can absolutely still store those in your password
| manager...
| triska wrote:
| 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
| dheera wrote:
| 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.
| brendoelfrendo wrote:
| 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.
| dheera wrote:
| Right, AWS is the biggest offender of this. Also, Coinbase,
| Kraken, and several others.
|
| Seriously, deprecate SMS already. I deprecated it 10 years
| ago.
| Closi wrote:
| 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.
| eikenberry wrote:
| 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.
| dheera wrote:
| 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.
| rkeene2 wrote:
| 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.
| meowtimemania wrote:
| 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?
| Jtsummers wrote:
| 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).
| hunter-gatherer wrote:
| 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.
| nonameiguess wrote:
| 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.
| Lammy wrote:
| >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)."
| Terretta wrote:
| 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_
| [deleted]
___________________________________________________________________
(page generated 2021-09-20 23:01 UTC)