7 ms·

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

by bdamm 5y ago

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.

NieDzejkob 5y ago
> 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 5y ago
  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 5y ago
    Not really. Compare https://www.johndcook.com/blog/2008/03/25/innovation-ii/ 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 5y ago
      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 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!
      - thaumasiotes 5y ago
        https://en.wikipedia.org/wiki/James_Lancaster#Scurvy https://en.wikipedia.org/wiki/James_Lancaster#Scurvy The navy is not a decentralized organization. Distribution of the results is not a concern.
        gerdesj 5y ago
        "In 1601 Captain Admiral James Lancaster unintentionally performed an experimental study of lemon juice as a preventive for scurvy." Unintentionally ... This is in 1747: https://www.bbc.co.uk/news/uk-england-37320399 https://www.bbc.co.uk/news/uk-england-37320399
        thaumasiotes 5y ago
        The unintentional part was that he had an experimental group and a control group. The experiment itself was not unintentional; he was already aware that the lemon juice should prevent scurvy. That's why the one ship of four that got the lemon juice was the ship he was on. The fact that the British navy still had no institutional knowledge of scurvy hundreds of years later is the point I'm making. They didn't know how to deal with it despite the fact that a cure had been known for several thousand years, and the navy itself had received James Lancaster's report over a hundred years prior. The navy's behavior reflects nothing other than a very severe failure that would have been trivial to fix at any time. The adoption barriers that caused the navy to kill thousands upon thousands of its own men over a period of centuries did not reflect any difficulty in preventing scurvy. It was always easy. They reflected the fact that adoption barriers are very large no matter what the context is, and absolutely overwhelming evidence, such as a 100% reduction in the incidence of a disease that ordinarily kills 40% of your manpower, is not enough to bypass them. The adoption of a practice is at most tenuously related to the effectiveness of a practice. That is not how people adjust their behavior. What point are you making?
- gfody 5y ago
  we've also had kerberos since the 80s, passwords are never shared it's all digests
a-dub 5y ago
> 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 5y ago
  Nope. Left as an exercise for the user and 2FA provider, and/or the service to provide an alternate recovery system.
  - a-dub 5y ago
    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 5y ago
      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).
    - tehbeard 5y ago
      There is some data you can get from them (Attestation I think is what the spec calls it?) though it's just a optional request response I think, the 2fa can ignore it by itself or at users discretion? But this data is more about the manufacturing of the 2FA device, and basically amounts to the "bin" it belongs to, like saying built in 2020, as part of batch 3. Vague enough to not really be identifiable, but useful if a flaw in a device is found in a particular model or such.
gerdesj 5y ago
"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?
- romwell 5y ago
  >"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/orwell/essays-and-other-works/politics-and-the-english-language/ https://www.orwellfoundation.com/the-orwell-foundation/orwel...
  - 5y ago
michaelt 5y ago
> 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.
megous 5y ago
And how do you protect your secret keys, if passwords are fundamentally broken?
JoshTriplett 5y ago
> 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.
SilverRed 5y ago
>Passwords must be shared to work, therefore they can never truly be secret. Password managers already fixed this. Your password is unique per website so it doesn't matter if the service knows it since they could already login as you anyway.
- Xylakant 5y ago
  An adversary with network access (looking at you, corporate firewalls) can read your password as well, not only your computer and the service. If the site uses a CDN, then it's likely that the endpoint for the TLS connection is the edge node, not the service itself and that the connection is re-encrypted from the node to the service (or even on an unencrypted connection from there on). An attacker may have breached the service and exfiltrate passwords. The service may have a config error and log plain-text passwords to an unsecured elasticsearch instance. The service provider may have bad security practices and store the password in plain text or using an insecure hashing scheme. All of these problems go away if you use some sort of asymmetric authentication since the public part is by definition public.
  - jve 5y ago
    > An adversary with network access (looking at you, corporate firewalls) Well, if you use corporate device, you implicitly trust them, don't you? Some even sign put signature on a paper agreeing what the corporate body can do to you. Perhaps MITM your encrypted traffic with corporate installed root cert or whatever. Otherwise if you use your own device, in the age of encrypted HTTP and other stuff - No, an adversary or corporate firewall cannot simply read your password.
    - blitzar 5y ago
      > Well, if you use corporate device, you implicitly trust them, don't you Well, if you use microsoft, you implicitly trust them, don't you Well, if you use <insert ISP>, you implicitly trust them, don't you Well, if you use the internet, you implicitly trust them, don't you
kobayashi 5y ago
SQRL seems like a good option that incorporates public/private keys as an alternative to passwords

by bdamm 5y ago

NieDzejkob 5y ago

> 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 5y ago
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 5y ago
  Not really. Compare https://www.johndcook.com/blog/2008/03/25/innovation-ii/ 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 5y ago
    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 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!
    - thaumasiotes 5y ago
      https://en.wikipedia.org/wiki/James_Lancaster#Scurvy https://en.wikipedia.org/wiki/James_Lancaster#Scurvy The navy is not a decentralized organization. Distribution of the results is not a concern.
      - gerdesj 5y ago
        "In 1601 Captain Admiral James Lancaster unintentionally performed an experimental study of lemon juice as a preventive for scurvy." Unintentionally ... This is in 1747: https://www.bbc.co.uk/news/uk-england-37320399 https://www.bbc.co.uk/news/uk-england-37320399
        thaumasiotes 5y ago
        The unintentional part was that he had an experimental group and a control group. The experiment itself was not unintentional; he was already aware that the lemon juice should prevent scurvy. That's why the one ship of four that got the lemon juice was the ship he was on. The fact that the British navy still had no institutional knowledge of scurvy hundreds of years later is the point I'm making. They didn't know how to deal with it despite the fact that a cure had been known for several thousand years, and the navy itself had received James Lancaster's report over a hundred years prior. The navy's behavior reflects nothing other than a very severe failure that would have been trivial to fix at any time. The adoption barriers that caused the navy to kill thousands upon thousands of its own men over a period of centuries did not reflect any difficulty in preventing scurvy. It was always easy. They reflected the fact that adoption barriers are very large no matter what the context is, and absolutely overwhelming evidence, such as a 100% reduction in the incidence of a disease that ordinarily kills 40% of your manpower, is not enough to bypass them. The adoption of a practice is at most tenuously related to the effectiveness of a practice. That is not how people adjust their behavior. What point are you making?
gfody 5y ago
we've also had kerberos since the 80s, passwords are never shared it's all digests

a-dub 5y ago

> 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 5y ago
Nope. Left as an exercise for the user and 2FA provider, and/or the service to provide an alternate recovery system.
- a-dub 5y ago
  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 5y ago
    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).
  - tehbeard 5y ago
    There is some data you can get from them (Attestation I think is what the spec calls it?) though it's just a optional request response I think, the 2fa can ignore it by itself or at users discretion? But this data is more about the manufacturing of the 2FA device, and basically amounts to the "bin" it belongs to, like saying built in 2020, as part of batch 3. Vague enough to not really be identifiable, but useful if a flaw in a device is found in a particular model or such.

gerdesj 5y ago

"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?

romwell 5y ago
>"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/orwell/essays-and-other-works/politics-and-the-english-language/ https://www.orwellfoundation.com/the-orwell-foundation/orwel...
- 5y ago

michaelt 5y ago

> 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.

megous 5y ago

And how do you protect your secret keys, if passwords are fundamentally broken?

JoshTriplett 5y ago

> 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.

SilverRed 5y ago

>Passwords must be shared to work, therefore they can never truly be secret. Password managers already fixed this. Your password is unique per website so it doesn't matter if the service knows it since they could already login as you anyway.

Xylakant 5y ago
An adversary with network access (looking at you, corporate firewalls) can read your password as well, not only your computer and the service. If the site uses a CDN, then it's likely that the endpoint for the TLS connection is the edge node, not the service itself and that the connection is re-encrypted from the node to the service (or even on an unencrypted connection from there on). An attacker may have breached the service and exfiltrate passwords. The service may have a config error and log plain-text passwords to an unsecured elasticsearch instance. The service provider may have bad security practices and store the password in plain text or using an insecure hashing scheme. All of these problems go away if you use some sort of asymmetric authentication since the public part is by definition public.
- jve 5y ago
  > An adversary with network access (looking at you, corporate firewalls) Well, if you use corporate device, you implicitly trust them, don't you? Some even sign put signature on a paper agreeing what the corporate body can do to you. Perhaps MITM your encrypted traffic with corporate installed root cert or whatever. Otherwise if you use your own device, in the age of encrypted HTTP and other stuff - No, an adversary or corporate firewall cannot simply read your password.
  - blitzar 5y ago
    > Well, if you use corporate device, you implicitly trust them, don't you Well, if you use microsoft, you implicitly trust them, don't you Well, if you use <insert ISP>, you implicitly trust them, don't you Well, if you use the internet, you implicitly trust them, don't you

kobayashi 5y ago

SQRL seems like a good option that incorporates public/private keys as an alternative to passwords