7 ms·

First and foremost, congratulations on bringing the project to this stage - I think it's an impressive piece of work. I am in no way qualified to trample on y

First and foremost, congratulations on bringing the project to this stage - I think it's an impressive piece of work. I am in no way qualified to trample on your parade but two things came to my mind that pinch a personal nerve of mine and I would really like to have alleviated by you or the folks who know that stuff: - if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility? - In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm? Again thank you for your work and congratulations on the project - those above are just honest questions that came to mind which I would really like to be educated on

getcrunk 5y ago
Passwords are not insecure. Certs have tradeoffs.
- dewey 5y ago
  I don't read it as "passwords are insecure" but as having defaults that force people into using it in ways that are harder to mess up. Re-using an insecure password is easy, using a key wrong is harder.
  - moondev 5y ago
    re-using an insecure key is just as easy https://github.com/mikalv/anything2ed25519 https://github.com/mikalv/anything2ed25519
  - LinuxBender 5y ago
    I understand what you are saying but in my experience the opposite can be equally true. Unless every system in your org is managing the authorized_keys for every account with automation and hourly validation one can end up with rogue keys, forgotten keys, unmanaged keys. SSH has no concept of identity in this regard. If I temporarily have sudo on a system I can append any random public key into the authorized_keys of any account. It gets even worse if that system allows passwordless sudo. Now there is an audit trail that showed you made a reckless change when it was really me. This risk gets exponentially worse if the system I append a random key into is a command and control or configuration management system. One doesn't even really need sudo for this to be a problem given how much power non root accounts have over applications, deployments, builds and secret management.
    - staticassertion 5y ago
      Is authorized keys important here? If I send the server my password, it has my password. If I send a server my public key, that's a lot less severe. If an attacker is on the server I expect that the difference is obvious?
      - LinuxBender 5y ago
        Both are vulnerable to phishing via malicious scripts. One could even argue that keys are more dangerous if the attacker can append their own key into authorized_keys one host at a time. Some might be surprised how incredibly easy it is to get a percentage of technical people on an email distribution to execute a script without fully understanding it and this is even leaving things out like compromising npm repositories. Said script can drop a key into authorized_keys or drop a custom key and create an outbound session invoking a gateway port allowing the attack to ssh to the host even if they have no inbound ports open. From there one can repeat the process as access is gained first at the workstation or laptop, then the jump host then build servers, repository servers, staging servers and ultimately production servers. SSH is a power communications tool. It is equally powerful to both the authorized user and to attackers in my experience. It is often poorly managed if even managed at all even in the most sensitive environments in some of the most high profile organizations.
        staticassertion 5y ago
        How would you phish my private key?
        LinuxBender 5y ago
        I would not. I would phish you running a script that adds my public key to your authorized_keys and would ssh from your client in the background creating a gateway port back to you. At that point I can get your ssh keys and just about anything else. If systems in your org allow ssh multiplexing default is enabled then I can also piggy-back your sessions bypassing MFA/2FA. I say you but I mean most people. I'm certain that you specifically would not fall for it but about 10% [1] of technical people will. [1] - stats based on past career and testing of a large technical population.
  - remram 5y ago
    I've received the private component attached via email before. People find a way to mess up.
- tialaramex 5y ago
  Passwords are a shared secret. I'm not sure I'd choose the word "insecure" but only because it's too black and white when the reality is more nuanced. They are clearly worse than doing public key auth which is the alternative and is Mandatory To Implement in the SSH (SecSH) RFCs. Nobody said anything about requiring certificates in SSH, just public keys as authentication.
  - SAI_Peregrinus 5y ago
    Strong aPAKES can allow passwords to not be shared secrets. Of course they're super niche now and none of them are standardized so they're basically impossible to use, and SSH doesn't support them, so this is a pedantic nitpick instead of some sort of insightful observation.
- tptacek 5y ago
  No they don't. Passwords are worse than certificates or keypairs, categorically.
  - willcipriano 5y ago
    > No they don't SSH into one of your boxes from my machine real quick.
    - boomlinde 5y ago
      Of all the use cases I can imagine, enabling password logins just so I can meaningfully type my password into strange computers is among the least compelling.
    - reggegg 5y ago
      What's the use case for using your personal unix account on someone else's computer?
      - tedunangst 5y ago
        My mail server crashed while I was on vacation without my laptop.
      - willcipriano 5y ago
        I've done it from work computers where the USB ports are disabled but I want to hit my personal dev machine at home to get at my notes and calendar. I've established impromptu SSH tunnels from other people's machines to my local network so that I could watch my media on their TV. If you dropped me naked on the other side of the planet I could get a copy of my identity documentation and access my email, bank accounts, etc from any internet connected machine I find.
        tptacek 5y ago
        You get that passwords over first-time SSH from untrusted computers or untrusted networks aren't safe at all, right? That posting those passwords is literally a sport at hacker conferences, and has been for over 2 decades? This whole thread is a little alarming.
- dspillett 5y ago
  Good passwords are usually not insecure. But if you give your password to a host that you don't 100% trust (i.e. that you didn't setup yourself locally) you have potentially shared that password and if you've reused it anywhere the other wheres are potentially compromised. If you give you public key to be installed to allow access, even if the host (or any system you are using to build/interact with it) is compromised your private key and any other hosts that accept authentication that way are fine. How much difference this makes to you depends upon your threat model and how much extra threat you are willing to accept for a little convenience, of course, but key based auth is demonstrably more secure than passwords for some circumstances and no less secure in others. Then again given that very few people bother actually checking host fingerprints on first connection, then proceed to send important data to that unverified host, is the password/key issue the first thing we need to fix?
m_sahaf 5y ago
> - if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility? Compatibility was the consideration. The presence of the password based authentication does not mean it is enabled by default. In fact, if you don't enable any of the authentication flows and don't explicitly set `no_client_auth` to `true`, the server will not accept any request at all! You have to explicitly set `no_client_auth` to `true` for the server to allow unauthenticated users to login. The default is: none of the authentication methods are configured, and `no_client_auth` is false (meaning do not allow clients without authentication). > - In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm? That was just an example, but the implementation doesn't only support github. It supports any HTTP/S URL you provide. The point was that the source of the keys may even be an internal HTTPS service within your network that applies its own logic for keys issuance and generation.
deleted 5y ago
[deleted]

getcrunk 5y ago

Passwords are not insecure. Certs have tradeoffs.

dewey 5y ago
I don't read it as "passwords are insecure" but as having defaults that force people into using it in ways that are harder to mess up. Re-using an insecure password is easy, using a key wrong is harder.
- moondev 5y ago
  re-using an insecure key is just as easy https://github.com/mikalv/anything2ed25519 https://github.com/mikalv/anything2ed25519
- LinuxBender 5y ago
  I understand what you are saying but in my experience the opposite can be equally true. Unless every system in your org is managing the authorized_keys for every account with automation and hourly validation one can end up with rogue keys, forgotten keys, unmanaged keys. SSH has no concept of identity in this regard. If I temporarily have sudo on a system I can append any random public key into the authorized_keys of any account. It gets even worse if that system allows passwordless sudo. Now there is an audit trail that showed you made a reckless change when it was really me. This risk gets exponentially worse if the system I append a random key into is a command and control or configuration management system. One doesn't even really need sudo for this to be a problem given how much power non root accounts have over applications, deployments, builds and secret management.
  - staticassertion 5y ago
    Is authorized keys important here? If I send the server my password, it has my password. If I send a server my public key, that's a lot less severe. If an attacker is on the server I expect that the difference is obvious?
    - LinuxBender 5y ago
      Both are vulnerable to phishing via malicious scripts. One could even argue that keys are more dangerous if the attacker can append their own key into authorized_keys one host at a time. Some might be surprised how incredibly easy it is to get a percentage of technical people on an email distribution to execute a script without fully understanding it and this is even leaving things out like compromising npm repositories. Said script can drop a key into authorized_keys or drop a custom key and create an outbound session invoking a gateway port allowing the attack to ssh to the host even if they have no inbound ports open. From there one can repeat the process as access is gained first at the workstation or laptop, then the jump host then build servers, repository servers, staging servers and ultimately production servers. SSH is a power communications tool. It is equally powerful to both the authorized user and to attackers in my experience. It is often poorly managed if even managed at all even in the most sensitive environments in some of the most high profile organizations.
      - staticassertion 5y ago
        How would you phish my private key?
        LinuxBender 5y ago
        I would not. I would phish you running a script that adds my public key to your authorized_keys and would ssh from your client in the background creating a gateway port back to you. At that point I can get your ssh keys and just about anything else. If systems in your org allow ssh multiplexing default is enabled then I can also piggy-back your sessions bypassing MFA/2FA. I say you but I mean most people. I'm certain that you specifically would not fall for it but about 10% [1] of technical people will. [1] - stats based on past career and testing of a large technical population.
- remram 5y ago
  I've received the private component attached via email before. People find a way to mess up.
tialaramex 5y ago
Passwords are a shared secret. I'm not sure I'd choose the word "insecure" but only because it's too black and white when the reality is more nuanced. They are clearly worse than doing public key auth which is the alternative and is Mandatory To Implement in the SSH (SecSH) RFCs. Nobody said anything about requiring certificates in SSH, just public keys as authentication.
- SAI_Peregrinus 5y ago
  Strong aPAKES can allow passwords to not be shared secrets. Of course they're super niche now and none of them are standardized so they're basically impossible to use, and SSH doesn't support them, so this is a pedantic nitpick instead of some sort of insightful observation.
tptacek 5y ago
No they don't. Passwords are worse than certificates or keypairs, categorically.
- willcipriano 5y ago
  > No they don't SSH into one of your boxes from my machine real quick.
  - boomlinde 5y ago
    Of all the use cases I can imagine, enabling password logins just so I can meaningfully type my password into strange computers is among the least compelling.
  - reggegg 5y ago
    What's the use case for using your personal unix account on someone else's computer?
    - tedunangst 5y ago
      My mail server crashed while I was on vacation without my laptop.
    - willcipriano 5y ago
      I've done it from work computers where the USB ports are disabled but I want to hit my personal dev machine at home to get at my notes and calendar. I've established impromptu SSH tunnels from other people's machines to my local network so that I could watch my media on their TV. If you dropped me naked on the other side of the planet I could get a copy of my identity documentation and access my email, bank accounts, etc from any internet connected machine I find.
      - tptacek 5y ago
        You get that passwords over first-time SSH from untrusted computers or untrusted networks aren't safe at all, right? That posting those passwords is literally a sport at hacker conferences, and has been for over 2 decades? This whole thread is a little alarming.
dspillett 5y ago
Good passwords are usually not insecure. But if you give your password to a host that you don't 100% trust (i.e. that you didn't setup yourself locally) you have potentially shared that password and if you've reused it anywhere the other wheres are potentially compromised. If you give you public key to be installed to allow access, even if the host (or any system you are using to build/interact with it) is compromised your private key and any other hosts that accept authentication that way are fine. How much difference this makes to you depends upon your threat model and how much extra threat you are willing to accept for a little convenience, of course, but key based auth is demonstrably more secure than passwords for some circumstances and no less secure in others. Then again given that very few people bother actually checking host fingerprints on first connection, then proceed to send important data to that unverified host, is the password/key issue the first thing we need to fix?

m_sahaf 5y ago

> - if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility? Compatibility was the consideration. The presence of the password based authentication does not mean it is enabled by default. In fact, if you don't enable any of the authentication flows and don't explicitly set `no_client_auth` to `true`, the server will not accept any request at all! You have to explicitly set `no_client_auth` to `true` for the server to allow unauthenticated users to login. The default is: none of the authentication methods are configured, and `no_client_auth` is false (meaning do not allow clients without authentication). > - In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm? That was just an example, but the implementation doesn't only support github. It supports any HTTP/S URL you provide. The point was that the source of the keys may even be an internal HTTPS service within your network that applies its own logic for keys issuance and generation.

deleted 5y ago

[deleted]