2. Use strong passwords, or public keys, for all accounts, regardless of how unimportant they seem. A strong password is one with letters, numbers, and possibly special characters, 8 or more characters in length, and is changed periodically.
3. Don't run unnecessary services or services with a poor recent security history.
Disabling the root login is a legit choice, though if someone figures out your sudo-capable account, you're equally screwed, so use strong passwords always.
Changing the ssh port only stops the people who aren't targeting you specifically, and even those people aren't always stopped. It is trivial to scan a host to find where ssh is running, regardless of the port you put it on.
fail2ban or denyhosts are OK for preventing brute force attacks, but OpenSSH and most security sensitive software already has timeouts, among other measures for preventing brute force attacks. Which makes fail2ban more of a nuisance-prevention measure (i.e. you see fewer brute force attacks show up in your log reports, and thus making it easier to see the more dangerous threats), rather than a core security measure.
If you performed your three steps, but ran an insecure version of any service (particularly those that have elevated privileges), you would still be easily exploited. fail2ban or denyhosts would prevent most services from being exploited due to weak passwords, so that's probably not a hole you'd have. And, changing the ssh port does nothing for you if your system hasn't been updated and is running exploitable services.
I used to do security cleanup and post-mortems and data recovery as a contractor for folks who'd had systems exploited. 90% of them were due to running old versions of software, and the rest were due to weak passwords (which may or may not have been prevented by fail2ban; in a couple of cases the exploiter used the webmail client to brute force the weak passwords...most people don't include the webmail client logs in their security considerations, and thus wouldn't configure fail2ban to ban attempts on the webmail client).
I'm not saying your advice is not useful, just that it's something you do after you get your core processes in order.
Great advice! You sound like you have a lot of experience in server security.
What is your recommendation on strong passwords? Also, should all passwords on a system be different (login passwords for different servers, email passwords, etc...), and if so, how do you keep track of all of them?
This is a good way to go about it. I use Supergenpass session (the bookmarklet version is exploitable by websites you visit) for Chrome for websites, and keys for most ssh purposes. I have a couple of strong memorized passwords for situations where keys and supergenpass aren't convenient.
I'm totally on board with having one long/strong passphrase memorized and using it to generate strong, seemingly random passwords algorithmically, and I assume that's what SHA1_Pass does. So, yes, using SHA1_Pass is probably a good way to go about it.
On the one hand, the hex password in the screenshot while quite long has only 16 possible characters. The Base64 password has only 60 possible characters to choose from (for each position) and must end with an equals sign.
The number of possible characters for each position in the original sentence is quite high (94) but in a sentence the actual likelihood of a wide range of combinations being used is quite low (unless deliberately using obsfucation).
It's a very interesting piece of software and presents a very interesting question, which I guess is this:
For a given sentence, which out of Base64 encoding, Base 32, Hex and the sentence make for the most permutations required to crack? If the answer is Base64, 32 or Hex then your tool is helping. If the answer is the sentence then your tool is impeding. I suspect (but haven't done the maths) that for purely single case alphanumeric passwords it'll be base 64, but for mixed-case alphanumeric with punctuation it'll be the sentence. Anyone care to do the sums to lock this down?
I think you're missing the point of something like SHA1_pass: A different passphrase for every site. In the case of SuperGenPass, it hashes the site with the passphrase, making a unique passphrase for every domain. In the case of SHA1_pass, I would do something like, "My wacky passphrase 123 facebook.com" and "My wacky passphrase 123 google.com", etc. if I were to use it.
The sentence is only a piece of the hashed value, while some unique thing about what you're logging into is the rest of it. So, using "My wacky passphrase 123 facebook.com" as my password directly on facebook.com would mean that anyone with malicious intent and access to facebook.com code could easily figure out that every website where I have an account is "My wacky passphrase 123 sitename.tld". Strong password failure. The one-way hashed version of that has no meaning to the sites I log in to.
So, original sentence has very low security value, while a hashed version of it (assuming a unique piece for every site or service) has very high security value, even if the actual password generated is less strong than the original sentence from a purely "number of possibilities" perspective.
Of course, if you always use the exact same passphrase, and thus the same resulting password, your math would make sense...but the likelihood of an exploit is far more likely to come from people behind one of the sites you use sniffing your password, than from a brute force attack, in either case.
As I understand it, SHA1_pass does the following (please correct me if I'm wrong or missing anything out):
* Takes a user supplied passphrase
* Makes a SHA-1 hash of the supplied passphrase
* Encodes the resulting hash in a variety of ways
I don't see where a different passphrase for every site comes in. You seem to be saying that you would append the site if you were to use it - you wouldn't need a tool like SHA1_pass to do that though.
I guess where I'm coming from is that I don't see what SHA1_pass does that provides any benefit over something like 1password or password gorilla, both of which can generate random passwords for arbitrary accounts.
Following your example, if I obtain your password on site A, then I get a hex|base32|base64 representation of a SHA-1 hash. I then put this into something like this (http://www.golubev.com/hashgpu.htm) and crack the SHA-1. I notice your algorithm for creating passwords and do the same. I'm now exactly where I would be if you weren't using your approach for a password on every site.
I appreciate that the SHA-1 element acts as an interesting intermediary, but your method for generating the password is predictable. I think a randomised SHA-1 might be better.
Author again. It should be used exactly as SwellJoe Described. The hash of "My Awesome password for Facebook!!!" should only be used on facebook.com. "My Awesome password for Twitter!!!" and so on.
The benefit of SHA1_Pass is that you never store, synchronize or backup passwords ever again. It's free, completely open-source and anyone can implement it and other software can be used to generate the hashes. Some of the password storage managers are not that way.
Spot on advice, and a valid rebuttal. My trifecta was more in the spirit of securing against hundreds of brute force attempts, but I can't really knock your excellent advice.
1. Update your software.
2. Use strong passwords, or public keys, for all accounts, regardless of how unimportant they seem. A strong password is one with letters, numbers, and possibly special characters, 8 or more characters in length, and is changed periodically.
3. Don't run unnecessary services or services with a poor recent security history.
Disabling the root login is a legit choice, though if someone figures out your sudo-capable account, you're equally screwed, so use strong passwords always.
Changing the ssh port only stops the people who aren't targeting you specifically, and even those people aren't always stopped. It is trivial to scan a host to find where ssh is running, regardless of the port you put it on.
fail2ban or denyhosts are OK for preventing brute force attacks, but OpenSSH and most security sensitive software already has timeouts, among other measures for preventing brute force attacks. Which makes fail2ban more of a nuisance-prevention measure (i.e. you see fewer brute force attacks show up in your log reports, and thus making it easier to see the more dangerous threats), rather than a core security measure.
If you performed your three steps, but ran an insecure version of any service (particularly those that have elevated privileges), you would still be easily exploited. fail2ban or denyhosts would prevent most services from being exploited due to weak passwords, so that's probably not a hole you'd have. And, changing the ssh port does nothing for you if your system hasn't been updated and is running exploitable services.
I used to do security cleanup and post-mortems and data recovery as a contractor for folks who'd had systems exploited. 90% of them were due to running old versions of software, and the rest were due to weak passwords (which may or may not have been prevented by fail2ban; in a couple of cases the exploiter used the webmail client to brute force the weak passwords...most people don't include the webmail client logs in their security considerations, and thus wouldn't configure fail2ban to ban attempts on the webmail client).
I'm not saying your advice is not useful, just that it's something you do after you get your core processes in order.
Edit: Formatting.