Tremulous Forum
General => General Discussion => Topic started by: Rocinante on October 19, 2009, 01:50:09 am
-
Please note that this thread is not a place to discuss the events of this weekend - once there's solid information to disseminate I'm sure that will be forthcoming - but instead this is to answer some questions I've seen repeated in email and IRC. Do try to avoid wild speculation and misinformation, and not bring up what so-and-so told you happened this weekend.
I've seen quite a few people question recent events, specifically when told there was a database breach and that passwords should be changed everyone asks, "But aren't they encrypted?" The answer is yes, of course they are. But that means nothing.
Passwords tend to be encrypted using what is called a "one-way hash"; this is a mathematical function where given a certain input, a specific output is generated. However, given the output, you cannot determine mathematically what the input to the function was - it only works in one direction. Some examples of one-way hashes are MD5, SHA1 and RIPEMD. See this article (http://en.wikipedia.org/wiki/Cryptographic_hash_function) for more on hashes.
Now, even though you can't mathematically determine what the input to a hash was, you can still "crack" it through other means. Some, such as MD5, have particular flaws that make it easier to calculate what the input was when given the hashed output, while for others there's the dictionary attack. For example, if my password was "p@ssw0rd", one possible hash of that is "A6.WLhKd.rk2M". While you may not easily be able to reverse that, what you can do is take every word of a dictionary (including variants, such as substituting 1 for i or l, 0 for o, etc) and hash that value to see what you get. Sooner or later, you're bound to find out that when using the input "p@ssw0rd" you get the same value. Now without cryptographically attacking the actual hash, you've defeated it because the password itself was weak.
If instead I had used "WA53@WaIOGxL;Qq" as my password.. well, yes you could eventually brute force that value and find that it matches the hashed output. But that's going to take a lot longer since the password itself is random. When cracking accounts, you'll get all the easy ones first - people who use their username as a password, or a common dictionary word, followed by those who prepend or append a number, change capitalization, or substitute some numbers and symbols for letters. So as you can see, it doesn't matter how strong an encryption algorithm is. If an attacker has your encrypted password, and you have a crappy password, and they know what method was used to encrypt it (which is usually the easiest part of the equation to get) then they can get your password. It's all a matter of how much CPU time they want to throw at the problem, and how patient they are to get your password as a result.
I invite and encourage any questions on passwords, encryption and security - I'll leave this topic here, even though it will quickly become "off topic" for the forum itself, until a few days have passed and those who would be interested in the idea have seen it here before moving it to the off topic board.
-
Thanks for the heads up!
http://gmailblog.blogspot.com/2009/10/choosing-smart-password.html
-
tl;dr: Put in the effort to memorize a longer and more complicated (and thus more secure) password.
Off topic:
Will we get some information on what actually happened this weekend? Or should I not even bother asking this?
-
Check my signature, it's my view of the matter. :P
Good article, thanks for explaining.
-
Thanks for the heads up. Password changed.
General Question: Is there any way of discerning where else a password may or may not have been used?
-
what about salting?
-
tl;dr: Put in the effort to memorize a longer and more complicated (and thus more secure) password.
Definitely. I use 1Password (http://agilewebsolutions.com/products/1Password) on the Mac/iPhone, some use KeePass (http://keepass.info/), and there's plenty of other secure password managers to help you keep track of not only what password is used, but where it's used (or even better, generate long and complex ones everywhere).
Off topic:
Will we get some information on what actually happened this weekend? Or should I not even bother asking this?
I'm pretty sure that's coming very soon.
General Question: Is there any way of discerning where else a password may or may not have been used?
Only using your memory, and trial-and-error. If you store passwords in Firefox, you can search its list of stored passwords, or there's even a plugin you can get that can dump the list of passwords to a CSV or XML file; pretty sure there's similar methods in all the major browsers.
what about salting?
In short, it helps, but it doesn't prevent. The long: Salting (http://en.wikipedia.org/wiki/Salt_%28cryptography%29) is adding some extra bit of information to the password, so that the encrypted data consists of the password plus that extra bit; in this way, you tend to create a stronger encrypted string since the data isn't just the password. However, if you know the salt method used this sometimes doesn't help much. SMF uses a slightly strange method (and this is published all over the web, as well as the source code, so it's not like I'm divulging anything special here): The encrypted string consists of your username + password + salt. So the only thing this prevents is a straight dictionary attack, because instead of encrypting every password possible, you have to encrypt every username + password + salt to get a single password. Programs like "Jack the Ripper", used for brute forcing password databases, work on the principal that there's a small number of salts and the rest of the encrypted strings are just the password. In the case of my example "p@ssw0rd" above, if four people had the same password you wouldn't know until you tried encrypting that word plus our usernames and the salt, whereas without the method used by SMF you would find all four passwords at the same time.
-
FireFox users can install the PasswordMaker plugin to get unique passwords for every website. The advantage is that these unique passwords are autogenerated, so you don't need to carry them with you on an USB stick or something.
-
keypass here. You can generate obscene passwords that you'll never remember, and keepass can live on your task bar. You can right-click copy just the password (which it is set to not show you) and paste it into wherever. It only lives for a short while in you copy buffer though, so you don't have to worry about pasting it into something else 5 hours later when you get back to your computer ;D
Linux and windows version, maybe mac, I haven't looked.
-
And what about password strengthening? I.e. taking hash of a hash 20k times (about 1-2 seconds of average PC speed).
-
Because that also kills the server.
-
a hash of a hash of a hash of a hash of a hash of a hash of a hash of a hash.... over 9000 times.
Yeah, Hash the Hashing Hashers!
-
keypass here. You can generate obscene passwords that you'll never remember, and keepass can live on your task bar. You can right-click copy just the password (which it is set to not show you) and paste it into wherever. It only lives for a short while in you copy buffer though, so you don't have to worry about pasting it into something else 5 hours later when you get back to your computer ;D
Linux and windows version, maybe mac, I haven't looked.
How secure is this basket you're putting all your eggs into? And I don't mean from haxors. How about friends and family with access to your computer?
People you know are generally more aware of and interested in your online stuff than most people.
No, I don't wear a tinfoil hat. It's a tinfoil top hat.
-
How secure is this basket you're putting all your eggs into? And I don't mean from haxors. How about friends and family with access to your computer?
People you know are generally more aware of and interested in your online stuff than most people.
No, I don't wear a tinfoil hat. It's a tinfoil top hat.
How much do you want? You can lock the DB with a key you keep on a thumbdrive if you wish, or a password only you know, or both. It only runs in the taskbar if you start the program, not on OS start and the windows version even locks that so you need to reopen the db (with however you've locked it) when you call it back from the taskbar.
You could even store it on an encrypted partition on a usb drive if you want to start getting crazy paranoid :P
-
The PasswordMaker Add-on for Firefox is pretty good. I use that so that every web site has a different password and I only have to remember one.
-
No, I don't wear a tinfoil hat. It's a tinfoil top hat.
Hah! I don't know what line of business you're in, but in mine tinfoil is too flimsy :>
Tuple spoke about KeePass, I can speak about 1Password - it also has a "master password" which is used to lock the keychain, and has settings which determine how often it locks and when. You can have a time limit (defaults to 20m), when the machine goes to sleep, or even whenever the screen saver starts as triggers to relock the keychain.
They've got a new system coming out soon where you can point a web browser at a .html file in the keychain (it's just a directory), enter your master password and using javascript access the contents for when you're not at your Mac. I use this for my Linux machine at work. Also an iPhone app which has two layers of "security", a four digit PIN you enter to open the app and a password you enter to unlock any of the passwords contained within (though you can loosen restrictions on a case-by-case basis if, for example, you want to only require the PIN for some passwords).
-
I don't trust those password managers:
If I lose my head, I will lose all my passwords but probably also all of my life. So losing passwords is the lesser threat.
If I lose the USB stick or the hardisk with the password manager or forget the masterpassword.. I am really fucked.
-
I know the passwords to my email. With that I can reset everything else.
Also, print the list out. Can't forget the password to a bit of paper.
I'm using keepassx, which is keepass for linux. It seems to work great. Keepass2 is supposedly better, but it wouldn't run under mono (I didn't try too hard) and things like Auto-Type don't work on linux, which is kinda a deal breaker.
-
Thanks for the info.
So as far as I can see, there are only two real disadvantages to using such a tool.
1. Eggs in the basket
If the security on the database is cracked, the security of all your associated accounts are also cracked. A big 'if'? Maybe but it's an inherent flaw nonetheless.
2. Dependency
If you don't learn to remember the individual passwords, you need this tool to log in to your accounts.
I won't be using one of these but I can see why you would.
-
Why is it even bad if someone cracks your password on tremulous.net? They can't even see your email by logging into the account, can they? As long as you didn't use the same username/password combo on a banking website or something, it doesn't seem like a big deal. It's not like you should really care if the hacker(s) want to defame your trem.net reputation.
-
Your email is very much visable in account settings. And if you have the same password on the forums as your email or any other site they know you are on they can get into it. And if you have the same password to your email account they can get anywhere.
-
Best password:
the 10,000-10,008th nucleotide pair of your 23rd chromosome
-
Best password:
the 10,000-10,008th nucleotide pair of your 23rd chromosome
Brute forced with the aid of The Human Genome Project? :P
-
Best password:
the 10,000-10,008th nucleotide pair of your 23rd chromosome
Armed with that information, I've only got 65,536 strings to brute-force. Muhahahaha!
I'll start with 'gattaca' strings on the off chance you liked that movie so much you restructured your DNA to prove your devotion.
-
Or even better. Since encoding is good, RNA encode them.
-
thank god i used 12345 instead of a word from the dictionary, AMIRITE?
-
thank god i used 12345 instead of a word from the dictionary, AMIRITE?
You, go change the combination on my luggage!
-
thank god i used 12345 instead of a word from the dictionary, AMIRITE?
please dont write my password on forums backwards k thx bye :p
-
thank god i used 12345 instead of a word from the dictionary, AMIRITE?
Not exactly a dictionary, but does this count (http://en.wikipedia.org/w/index.php?title=12345&redirect=no)?
-
Which hashing algorithm was used on the passwords?
-
Which hashing algorithm was used on the passwords?
Out of pure curiousity amirite? ;)
-
md5. Not that it really makes much difference.
-
md5. Not that it really makes much difference.
It does to me because it lets me know the overall likelihood of a hashed password being recovered due to significant differences between the hashing algorithms.
MD5 is unfortunately a very weak choice of hash compared to other contemporary options. There really is no reason to not be using SHA-512 at this point in time and the administrators would be wise to reconsider their choice of MD5. Anyway, we can take away the emotional fear of a hashed password being recovered by looking at the statistics:
I believe the passwords here can consist of mixed upper and lower case alphabetic characters plus numbers, so this gives 62 different possible characters.
If you had an 8 letter password that was random, the total hash space is 62^8. To put that in to context, 62^8 = 2.18340106 × 1014 total amount of possible different passwords, which is, a relatively huge number. (This presumes the hashes were unsalted, which would increase the hash space significantly).
If someone were to generate a hash for each password that 62^8 allows, you would need approximately 6.2 pebibytes of hard drive space to store every hash. You would then need a supercomputer or cluster of supercomputers to find your hash in that table. Alternatively you could generate the hashes as you go.
It is therefore unviable that any random 8 letter password could be recovered from the MD5 hash alone by civilian or corporate resources. It could be viable for an intelligence agency to recover your password from a hash, however it would be a very expensive use of cracking resources and could take days, weeks, or even years depending on how much processing power was allocated to the recovery. There does however always remain the possibility that the cracker gets lucky and recovers the password on the first random guess, however the odds of this happening are so low one should not concern themselves with this consideration.
If your password was weak though, either in respect of being a word in the dictionary, less than 8 letters long, or even a variant of a word in a dictionary, you have shot yourself in the foot and have dramatically reduced the time to recoverability of the password, even by motivated civilians. I would suggest to anyone who engages in this malpractice to seek a random password generator a generate a 10 letter password and remember it. Sure it will be hard at first, but you'll get there.
-
Why is using MD5 bad for this?
The only difference SHA256 would make is extra server load.
-
Why is using MD5 bad for this?
The only difference SHA256 would make is extra server load.
Given the low loads on the server, this would most likely not be an issue. If this were a forum that millions of people use (for example, like the World of Warcraft forum), then indeed there would be a performance difference and one would be wise to consider all options depending on your goals. For a database with a few thousand password hashes the server would need to be absolute obsolescent junk for there to be a performance issue. In all other cases where server performance is not a consideration, the most rational choice is to choose the solution deemed most secure.
The reason that MD5 is bad for this is because of the recoverability issue when bruteforce measures are applied. At the moment it is presumed by some academics that very large and well financed organisations may be able in an emergency to retrieve MD5 hashes for a password of say 8 characters in a matter of days. In 10 years time the recoverability will be an order of magnitude easier and could be in the realms of minutes to seconds if MD5 hashes are used. Furthermore, that MD5 database that was stolen from the server will at some point later in our lifetimes, be effortlessly bruteforceable by the computers we own in our own homes.
While MD5 is ok for many purposes, SHA-256 and SHA-512 produce longer hashes that vastly increase the hash space that needs to be searched by a brute-force attack, rendering that attack vector neutralised.
An example hash for the password "tremulous":
MD5: ec4287009e6d3ab10c9604baa5c0afa4
SHA-512: 361c5def14777236655f906624d7560ffe575591ffc5b2fcd 49e6299338fb87d5948a46a79cc777271f707fcab084cf1b5 c32cb048f1afc4ec7a943b661ee429
Each additional byte in a hash output hardens up the resistance by orders of magnitude. Crucially, the reason for this is that although every (unsalted) password leads to a unique hash, very few hashes would lead to a password that would meet the constraints of being 8 letters long and randomised from 62 characters. If you use MD5, the amount of 'useless' hashes is much less so you can afford computationally to just try them all anyway. With SHA-256 or SHA-512 the 'useless' hash space relative to any particular password is so huge it would be like trying to find a pebble in an area of water the size of the solar system.
In my view it is the difference between following up a security breach by saying "the password hash database has been stolen, change your passwords", or "the password hash database has been stolen, if your password was even remotely secure it will probably take beyond the age of the the universe to recover your password".
-
The length of the output has no effect on a brute force attack (i.e. you try all reasonable keys). This obviously depends only on the number of possible keys.
If you talk about hash collisions, then a longer hash output reduces the probability, but given the assumed 62^8 keys and the 2^512 possible MD5 outputs, the number of key collisions within this key space is negligible (even if you consider the birthday paradox).
-
The length of the output has no effect on a brute force attack (i.e. you try all reasonable keys). This obviously depends only on the number of possible keys.
If you talk about hash collisions, then a longer hash output reduces the probability, but given the assumed 62^8 keys and the 2^512 possible MD5 outputs, the number of key collisions within this key space is negligible (even if you consider the birthday paradox).
In my examples, I have used output length as an observable guide to key space. The reason I propose that this is a sane utility is that a.) observable phenomena aid understanding and b.) contemporary cryptographic hash functions have a positive correlation between output length and key space.
Given the real but unlikely threat of hash collisions in algorithms like MD5 and SHA-1, I have opted not to discuss them as items worthy of concern.
To address the central aspect of your post more directly, it's a matter of what one considers 'reasonable keys'. If you mean a dictionary attack of millions of commonly used passwords and variations of them, those hashes already exist and all one needs to do is search through the database without having to bother doing any hashing computation at all. If 'reasonable keys' means to you random 8 letter passwords with each character derived from a pool of 62 possible combinations then that database doesn't exist because as I discussed in my original post there ~218 trillion possible passwords and the storage space would be immense. For SHA-512 you still have the same ~218 trillion possible passwords, however a.) given the cumulative increased computational effort required to generate an SHA-512 hash vs and MD5 hash, and b.) as it's a much longer hash, you need a much larger storage space.
This should make people understand why a weak password is useless, regardless of which algorithm you choose to use.