8

I manage about 20+ Linux servers and I am considering using an md5 scheme similar to following to generate the admin passwords:

echo 'masterpassword' 'serverhostname' | md5sum

Which returns 4db2430f9b5f788077fd36636002e391 using the above example.

My question is: Given that I always put a space before the command to keep the command out of my bash history, do you see any glowing issues with this scheme?

I do not remember where I read about doing it this way, but it sounds like a pretty good idea and I wanted some feedback before I make it official and add it to my DR plan.

Note: Keep in mind that this is just a scheme to generate a password. for example, echo -n 'M4M@st3rPa$$W0rd' 'www.domain.com.1' | md5 generates a7c2dc2a7a2a1d277353e1fb814f57f1 which would be the actual password. One of my challenges is that I get help from a managed service provider, and in case of emergencies, I may need to give them ssh access to a server and needed a way to easily remember secure passwords while I am on the road.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
InChargeOfIT
  • 193
  • 6
  • 1
    One of my concerns would be how you are storing these passwords? – Mark Beadles Feb 23 '12 at 21:06
  • It sounds like it's one typo away from being in your bash history but that's not a big concern. I don't see any advantage in including the hostname over just using the master password. What threat are you trying to mitigate? – Ladadadada Feb 23 '12 at 21:28
  • @Ladadadada he wants per site passwords, while only remembering a single one. – CodesInChaos Feb 23 '12 at 22:30
  • 1
    From "...add it to my DR plan" I'm guessing this is going into some sort of "rebuild everything from scratch" script? If so, pretty clever. I'd still be inclined to replace them with "real" passwords afterwards though. – scuzzy-delta Feb 23 '12 at 22:34
  • @MarkBeadles these passwords will be stored in the shadow file (SHA1). – InChargeOfIT Feb 23 '12 at 23:28
  • @Ladadadada yeah, I can see this getting into the bash history easily... I will just have to be mindful. I am trying to mitigate pass-the-hash style attacks (even though I am unaware of any on Linux). – InChargeOfIT Feb 23 '12 at 23:31
  • 2
    I might not be understanding your question here, but why not just generate random passwords and store in a keepass database? To facilitate management you could even set an auto type that will spit out an ssh connection line for remote admin when you need to get the password. A password is something you know, if its algorithmic they are all broken once one is broken. I would generate the passwords using a random bit, and why not, salt it with the server name. I don't know any of my passwords, and that is the way I like it. – Eric G Feb 24 '12 at 05:29
  • Maybe because `echo` and `md5sum` is much easier, securer, and available everywhere? KeePass is a fat GUI application for Windows, written in C#. AFAIK it runs under Linux only under MONO. – Andreas Spindler Jul 01 '13 at 14:43

4 Answers4

8

A few ideas:

  • Use a scheme that allows you to easily "bump" the passwords to a successive value for when the passwords need to be changed. If you ever need to give someone your server password (which does happen in certain types of emergencies), then you'll want to change the password in order to revoke access. Don't block yourself into keeping a password you can't easily change.

  • Don't use passwords for day-to-day interactions with the server. SSH keys are categorically better, especially when you have lots of servers to manage. Learn how to use an ssh key agent (ssh-add on *nix, and pageant on windows), which helps you simplify key management and gives you no excuse for not encrypting your private key.

  • Also, LastPass. Not really relevant to ssh and root passwords, but if you're managing lots of servers, you'll probably be putting lots of passwords into browsers. This is secure and reduces your incentive to re-use passwords.

As an implementation note, I just wanted to point out that your hash input has an implicit \n at the end that gets put there by echo. So if you ever attempt to replicate the password in Perl or using some other tool, just keep that in mind. Alternately: echo -n 'foo' 'bar' | md5sum. See also: echo $(</root/secret.txt) "hostname" | md5sum

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 1
    +1 for "use SSH keys, not passwords". I'd +1 again for LastPass if I could. – D.W. Feb 24 '12 at 06:43
  • I do use keys for my daily activities and I also use 1Password which is similar to LastPass. Great catch on the \n! – InChargeOfIT Feb 25 '12 at 00:24
  • 1
    BTW `echo -n` is not standardized by POSIX. The behaviour of `-n` and also the behaviour about backslash sequences is implementation defined. This means `echo -n` may not work; the better solution is `printf`. – Andreas Spindler Jul 01 '13 at 14:51
4
  • The server hostname is not a secret
  • MD5 is essentially compromised (https://en.wikipedia.org/wiki/MD5#Security). I am unsure as to whether MD5's particular weaknesses are exploitable in this scenario though, as they are mostly collision vulnerabilities.

The problem you're trying to solve, remembering 20+ root passwords, can be solved more securely using one of the following routines:

  • Use ssh key authentication instead of passwords (but be sure to have a good passphrase for your keys); this is not only more secure, but you can also revoke access for any key at any time by simply deleting the pubkey from the server. This is, by far, the best method I can think of.
  • Generate random passwords (cat some bytes from /dev/random, massage into password material) and store them in an encrypted file that you carry around. GPG encryption with a good key and passphrase should do the trick; since GPG defaults to decrypting to stdout, the risk of accidentally leaving the passwords in an unencrypted file or your history is small; it will of course remain in your terminal's line buffer. Obviously, this means you need to have your private key handy whenever you need to decrypt that file.
  • Use a third-party single-password solution like LastPass. This is only an option if you trust the third-party solution though.
tdammers
  • 1,776
  • 9
  • 14
  • 1
    The server hostname is (obviously?) being used as a salt. Salt is not secret and used to prevent rainbow table attacks. – logicalscope Feb 24 '12 at 16:42
  • 2
    It's not really a 'salt' as such when employed this way - it may or may not protect against rainbow tables depending on how random the hostnames are and how random the 'master password' is. However, it might help disguise the fact that the servers all have the same effective password. – Mark Beadles Feb 24 '12 at 19:41
  • MD5's vulnerabilities are irrelevant here (as you note, they're about collisions, not preimages). On Linux you should [use `/dev/urandom`, not `/dev/random`](http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939). Other than that, good advice. – Gilles 'SO- stop being evil' Jul 02 '13 at 07:42
  • @Gilles: `/dev/urandom` "reuses" entropy from `/dev/random`, and while this is sufficient in most cases, the blocking that `/dev/random` suffers from is not generally a problem when interactively generating a single password, so I prefer to be on the safe side in this case. – tdammers Jul 02 '13 at 08:08
1

This main risk I see is this. The 'serverhostnames' are (very probably) not secret information, so if the master password is compromised, then they all are.

EDIT: Additionally, it seems that your 'master password' is not random. You don't mention whether you have any rules for choosing it (such as length, character types, etc.)

If you use passwords, you should make them high-entropy and resistant to dictionary and password-guessing attacks. Best would be to generate a maximum-length random password over the full character set, and follow NIST guidelines on creating a high-entropy password.

Mark Beadles
  • 3,932
  • 2
  • 20
  • 23
  • I don't understand this answer, but thanks for the link. Effectively the hashed string is "masterpassword serverhostname\n". How should anyone guess (1) the "serverhostname" prefix, that (2) `echo` (without `-n`) was used and (3) that the actual passphrase is some `md5` output? Ok, it has been made public here, but this scheme can be easily modified. What the TO posted here seems to be a scheme that balances safety and usability very well, which IMHO is worth more than perfection. – Andreas Spindler Jul 01 '13 at 15:01
-3

The first "glowing issue" I see here is that this scheme does not use the entire ASCII character set. The entropy is not as good as it could be (see password strength).

This leads directly to the second issue. passwordmeter tells me the hash-key for "1234" (e7df7cd2ca07f4f1ab415d457a6e1c13) has the same strength as that for "So Long, and Thanks For All the Fish" (8121c5d059fd0a23dc7a436c56085188). So your master password can be simple, like a birth date or a chipcard PIN code, or complex, without gaining more entropy.

EDIT:

I understand the critics and the downvotes. Sorry, my post was not complete. The misunderstanding is that I did not meant the hash-key to be used directly as password, but as the password for TrueCrypt volumes, or GnuPG. As TrueCrypt uses PBKDF-2 to store keys internally, for example, it should be impossible for an attacker to find this key. Note also that it is impossible to pre-calculate and store all MD5 sums, even not the first 2^64 ones. And MD5 is just an example; in practice you would rather use SHA-1 or SHA-256.

On the other hand you (and only you) can easily reproduce the key. You can even give the plain password to a friend - as long as nobody knows the algorithm/salt you apply on it the password should be useless. A simple password that is already listed on the internet may even protect you then.

Andreas Spindler
  • 95
  • 3
  • 3
    Using the entire ASCII character set [is](http://xkcd.com/936/) [useless](http://security.stackexchange.com/q/6095) and often counterproductive. Using only lowercase letters and making the password 4/3 as long gives you the same entropy and makes it easier to type (especially on mobile devices). passwordmeter.com's advice is pretty bad, it values special characters far too much. A password meter cannot give good advice anyway because [it's not the password that matters but how it's generated](http://security.stackexchange.com/a/37739). – Gilles 'SO- stop being evil' Jul 02 '13 at 07:39
  • passwordmeter was just an example (anybody can see that it prefers special characters). And as far as I saw this thread did not ask for passwords that are easy to type, rather for a simple scheme that generates secure password from easy to remember strings (constant "masterpassword" plus variable domain-name). Using echo+md5sum as a scheme is not enough. This is what I wanted to express. – Andreas Spindler Jul 02 '13 at 08:14
  • 1
    “So your master password can be simple, like a birth date or a chipcard PIN code, or complex, without gaining more entropy.” No, this is completely wrong. [Read this, really.](http://security.stackexchange.com/a/37739) Passwordmeter doesn't know how the md5sum was generated and will give roughly the same score to any md5sum, regardless of the entropy. Don't use passwordmeter, the information is just not useful. Instead, measure the entropy. Not the entropy of the password, because there's no such thing, but the entropy of the password **generation process**. – Gilles 'SO- stop being evil' Jul 02 '13 at 08:57