4 ms·

Or just disable password-based authentication. These "attacks" are little more than log spam and are meant to prey on systems that host novice users with weakpa

by yock 15y ago

Or just disable password-based authentication. These "attacks" are little more than log spam and are meant to prey on systems that host novice users with weakpasswords. Require PKI and the log spam goes away.

radimm 15y ago
sure, I hope nobody is using password based authentication for SSH anyway :)
- pbhjpbhj 15y ago
  Is there an active exploit? Or are you just saying that this is the weakest form of auth for SSH?
  - bwarp 15y ago
    password is the weakest form of authentication on open systems i.e. ones which you have to hand over to monkey grade users. If you have a reasonable password policy yourself, I very much doubt it will cause you any problems. I've been attacked by these for 10 years, probably totalling millions of attempts and I have a user name in their databases but due to a sensible password, nothing has got in. I tend to use PKI and keyboard interactive logins though.
- mike-cardwell 15y ago
  And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.
  - rwmj 15y ago
    No .. but it would damn cool if such hardware existed. Does it?
    - seabee 15y ago
      Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar purpose, but my motivation levels correlate with my paranoia :) [0] http://www.rsa.com/node.aspx?id=1156 http://www.rsa.com/node.aspx?id=1156
      - mike-cardwell 15y ago
        I have a yubikey myself. The smart card method is much better though. When using a smart card, it is impossible even for the owner (who knows the access pin) to read the actual key. The crypto operations involved in the authentication take place on the card it's self. The smart card is protected by a pin, and will wipe it's self if the pin is entered incorrectly too many times. You can even use a smart card reader with a hardware pin pad built in so neither soft nor hard keyloggers can intercept it.
        rdl 15y ago
        The weak point is you still don't know what you're signing, who or what you're authenticating, etc. if you don't have a trusted display and do the entire transaction on trusted hardware. (your host may be compromised, and could show arbitrary data, proxy connections, etc.) Protecting the key does go a long way, but even with a secure passphrase input and smartcard key operations, there is risk. The ideal, IMO, would be some secondary hardware with a limited, secure OS which lets you put specific limits on how the key is used, showing a hash or identifying details of each transaction on the secure display, prompting you to verify each. E.g. to send a payment, the amount and payee (and date/sequence number) are shown on the secure display to verify before authorizing.
    - mike-cardwell 15y ago
      Yes it does. And it's pretty cheap too. I have an OpenPGP v2 smart card and an SPR-532 smart card reader. I will be writing up how I did it on my blog at https://grepular.com/blog/ https://grepular.com/blog/ probably next week. Need to find an hour or two to write the thing up.
  - bradleyland 15y ago
    "as long as they..." See, that's exactly why we don't allow password based authentication. While you can enforce strong passwords, you can't enforce that the user choose a password that is unique to your system, because you cannot know where else they may use this password. The recent Dreamhost security disclosure is a great example. What are the chances that a contractor is using the same password for a Dreamhost shell account as they are my server? Pretty high, in my experience. By disallowing password authentication, and requiring SSH-key auth, and requiring that contractors use a passphrase with their SSH-key, I have decreased the chances of a random break-in significantly.
    - mike-cardwell 15y ago
      How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.
      - pavel_lishin 15y ago
        Why, it's simple! They just send him their private key along with the passphrase, and he tests it to make sure it works! (I've heard worse.)
        mike-cardwell 15y ago
        For the sake of those who may not realise: You can take a password protected ssh key and remove it's password protection (if you know the password). And do the opposite of course (adding a password to a key without one)
      - bradleyland 15y ago
        I personally stand there with them (or over Skype) and ask them to show me how they manage their keys. Most devs know how to use ssh-agent. Those who don't are really excited to learn that they can increase security without an increase in effort. Password uniqueness, on the other hand, is something that requires continuous effort. There's an ongoing temptation to reuse the strong password that they've memorized for my server in other locations. Like most things in security, it's a matter of layering and balance. You layer your security, and you stop at the point where the added effort doesn't justify the added security. I view the progression like this OK: Strong passwords Better: SSH-key authentication (much harder to brute force, not susceptible to disclosure through third-party security disclosure) Best: SSH-key authentication with passphrase (prevents unauthorized use of private key if stolen) Insane: SSH-key stored on external drive with imaginary super-encryption
  - rat87 15y ago
    Whats wrong with writing it down on a sticky note taped to the box if the box is in a locked area?

by yock 15y ago

radimm 15y ago

sure, I hope nobody is using password based authentication for SSH anyway :)

pbhjpbhj 15y ago
Is there an active exploit? Or are you just saying that this is the weakest form of auth for SSH?
- bwarp 15y ago
  password is the weakest form of authentication on open systems i.e. ones which you have to hand over to monkey grade users. If you have a reasonable password policy yourself, I very much doubt it will cause you any problems. I've been attacked by these for 10 years, probably totalling millions of attempts and I have a user name in their databases but due to a sensible password, nothing has got in. I tend to use PKI and keyboard interactive logins though.
mike-cardwell 15y ago
And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.
- rwmj 15y ago
  No .. but it would damn cool if such hardware existed. Does it?
  - seabee 15y ago
    Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar purpose, but my motivation levels correlate with my paranoia :) [0] http://www.rsa.com/node.aspx?id=1156 http://www.rsa.com/node.aspx?id=1156
    - mike-cardwell 15y ago
      I have a yubikey myself. The smart card method is much better though. When using a smart card, it is impossible even for the owner (who knows the access pin) to read the actual key. The crypto operations involved in the authentication take place on the card it's self. The smart card is protected by a pin, and will wipe it's self if the pin is entered incorrectly too many times. You can even use a smart card reader with a hardware pin pad built in so neither soft nor hard keyloggers can intercept it.
      - rdl 15y ago
        The weak point is you still don't know what you're signing, who or what you're authenticating, etc. if you don't have a trusted display and do the entire transaction on trusted hardware. (your host may be compromised, and could show arbitrary data, proxy connections, etc.) Protecting the key does go a long way, but even with a secure passphrase input and smartcard key operations, there is risk. The ideal, IMO, would be some secondary hardware with a limited, secure OS which lets you put specific limits on how the key is used, showing a hash or identifying details of each transaction on the secure display, prompting you to verify each. E.g. to send a payment, the amount and payee (and date/sequence number) are shown on the secure display to verify before authorizing.
  - mike-cardwell 15y ago
    Yes it does. And it's pretty cheap too. I have an OpenPGP v2 smart card and an SPR-532 smart card reader. I will be writing up how I did it on my blog at https://grepular.com/blog/ https://grepular.com/blog/ probably next week. Need to find an hour or two to write the thing up.
- bradleyland 15y ago
  "as long as they..." See, that's exactly why we don't allow password based authentication. While you can enforce strong passwords, you can't enforce that the user choose a password that is unique to your system, because you cannot know where else they may use this password. The recent Dreamhost security disclosure is a great example. What are the chances that a contractor is using the same password for a Dreamhost shell account as they are my server? Pretty high, in my experience. By disallowing password authentication, and requiring SSH-key auth, and requiring that contractors use a passphrase with their SSH-key, I have decreased the chances of a random break-in significantly.
  - mike-cardwell 15y ago
    How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.
    - pavel_lishin 15y ago
      Why, it's simple! They just send him their private key along with the passphrase, and he tests it to make sure it works! (I've heard worse.)
      - mike-cardwell 15y ago
        For the sake of those who may not realise: You can take a password protected ssh key and remove it's password protection (if you know the password). And do the opposite of course (adding a password to a key without one)
    - bradleyland 15y ago
      I personally stand there with them (or over Skype) and ask them to show me how they manage their keys. Most devs know how to use ssh-agent. Those who don't are really excited to learn that they can increase security without an increase in effort. Password uniqueness, on the other hand, is something that requires continuous effort. There's an ongoing temptation to reuse the strong password that they've memorized for my server in other locations. Like most things in security, it's a matter of layering and balance. You layer your security, and you stop at the point where the added effort doesn't justify the added security. I view the progression like this OK: Strong passwords Better: SSH-key authentication (much harder to brute force, not susceptible to disclosure through third-party security disclosure) Best: SSH-key authentication with passphrase (prevents unauthorized use of private key if stolen) Insane: SSH-key stored on external drive with imaginary super-encryption
- rat87 15y ago
  Whats wrong with writing it down on a sticky note taped to the box if the box is in a locked area?