Slashdot Mirror
Ophcrack Says Your Password Is Insecure
javipas writes "An insightful article at Jeff Atwood's Coding Horror reveals the power inside Ophcrack, an Open Source program that is capable of discovering virtually any password in Windows operating systems. The article explains how passwords get stored on Windows using hash functions, and how Ophcrack can generate immense tables of words and letter combinations that are compared to the password we want to obtain. The program is available in Windows, Mac OS and Linux, but be careful: the generated tables that Ophcrack uses are really big, and you should allow up to 15 Gbytes to store these tables."
pre generated codes...yawn... didn't we have the same sort of thing - a database of md5 hashes - like a over a decade ago?
My new password is "1nm3ns3"
...generate inmense tables of words
Anybody got a link to the 15GB rainbow table file?
Ha, I've got these fools beat! I don't even USE a password on my Windows box. I'd like to see you try and crack MY password!
How long have rainbow tables been around? And hasn't just about everyone stopped storing LM hashes?
So basically, if I want to find out the passwords on someone else's computer, I have to bring along a high capacity DVD's-worth of data as well? I might as well just pretend I'm their tech support and ask for the password.
Back in the day, getting Windows passwords was as easy as opening a program from a floppy. That's how I got an A in Spanish class when the teacher challenged us to guess what his screensaver password was (the prize was an A for the year - dumb teacher).
or Lobster Thermidor a Crevette with a mornay sauce served in a Provencale manner with shallots and aubergines garnished with truffle pate, brandy and with a fried egg on top and SALT!!
if i have physical access to the machine and have a bootable CD i have no need to crack any passwords
i can just reset the password and carry on, i have a customer whos 9yo girl showed me how she "cracks" her brothers password by booting in safe mode and simply removing his password
luckliy in some ways iam glad windows is insecure, i can only imagine the hell a user (and MS) would go through when you tell them that their entire photo/music collection is toast because they forgot their 21 random character hard to remember password
dont blame the user blame the whole crappy password concept
"Passwords should never be saved as plaintext"
/etc/passwd, bitch!
Tell that to
Second, if you've computed all possible hash values for all possible character combinations, then it really doesn't matter what your password is, since you only have to have the input hash to the correct hash value. Since an infinite number of character strings map to a finite number of hash values, it is only a matter of building the tables before you can hack any system.
Third, if your only defense against this type of attack is a single password, you're screwed.
Fourth, if you are worried about this sort of attack and you still live with your parents, it's probably not really too critical that you implement heavy-duty, multiple-hardened points on your Gentoo system right now. You'll have plenty of time to implement that sort of security after you finish your current bag of Cheetos.
15GB isn't large enough to handle the possible combinations...
Aside from the fact that you need access to those Hashes in the first place...
Ophcrack live (CD) does not crack all windows passwords, only about 99%. Still it uses only 20 minutes and can crack passwords up to 14 characters, while running from a bootable CD. And it is horrifying how few windows sysadmins who know about this...
And that's exactly the reason why I prefer using passwords like: k|$$mY/\rs3
(blank)
password
password1 That formula will crack 90% of Windows passwords out there. The remaining 10% are what the other 14.999999 GB in the table are for.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
The title is a bit of a stretch. Some simple techniques can help protect your self from these attacks. Using special characters will greatly increase the strength of your password, since the rainbow set for ALL characters is 64GB in size. Also, a LONG password, even of simple word can increase the complexity due to its length. Something as simple as my!dear!aunt!sally would be far stronger than 1pass!
Some additional info on this topic can be seen here: http://druid.caughq.org/papers/Mnemonic-Password-Formulas.pdf
Windows has a security feature it uses when a user attempts to create a 15Gb table called "crashing". This makes it extremely difficult to break in using the tool defined.....
"Saltmakeseverythingbetter"...
WHEN SOMEONE HAD TO SPEND ONE NIGHT IN JAIL because he put too much salt on a burger?
http://www.msnbc.msn.com/id/20677230/?GT1=10357
I don't speak broken English. Can someone translate TFS for me?
"but be careful: the generated tables that Ophcrack uses are really big, and you should need up to 15 Gbytes to store these tables."
Since when 15 gigs were considered "really big"?
Aren't people at conferences handing out USB sticks as schwag with 493424 gigs these days in exchange for your business card?
Res publica non dominetur
Put a few non-numbers and non-letters in the password. That short 160 second breaking time will balloon up very quickly.
This is a prime example of the need for a multi layered security model for authentication and authorization of your systems. There are many vendors that supply two factor authentication methods (RSA being the most well known) that provide for one time passwords. Techniques like this effectively mitigate the risk of a user account compromised by use of a hash table like this. BTW, this is nothing new. Rainbow tables have been out for ages. --Colin
Colin McNamara - CCIE #18233 "The difficult we do immediately, the impossible just takes a little longer"
The key phrase in that sentence is "Most people" as in everyday users, and not security professionals and clued-in sysadmins. You know, the non-technical people who may have relied on Microsoft's password checker to tell them that their shit password is "strong" even though it could be cracked in 160 seconds.
>If I remember correctly...
Is this another way of saying "I'm about to spew forth a load of FUD".
I guess if it's anti-microsoft FUD, it'll get modded up, right.
First of all, ophcrack only comes with alpha-numeric tables for LM hashes. If you have special characters in your password, you'll have to generate your own table, which takes a very long time, and a lot of hard drive space. Ophcrack does not have the ability to generate Rainbow tables as the article suggest... Second of all, Ophcrack only works well against LM hashes, because with LM hashes, passwords are split into 7 byte halves, then hashed. So you only have to have tables that go up to 7 characters with LM hashes. If you disable LM hashes on your Windows box, and use NTLM hashes, the entire password is hashed, and is not split up. So if you pick a good password, with special characters, that's fairly long, it will be pretty much impossible to crack if your using NTLM only. Even with rainbow tables... The problem is Windows XP (by default) stores passwords as LM and NTLM hashes. So if an attacker can get the LM hashes, they can crack your password easily. You can hack the registry and keep Windows from storing LM hashes. See http://support.microsoft.com/kb/299656
That may have easily been true for NT 4.0, but (IIRC) Win2k and later stretches 'em out a lot more than 8 chars, esp. with AD password policies turned on. (No, not defending 'doze per se, but it simply doesn't parse IMHO).
But then, NT 4.0 once let you have perfect access to its SAM registry keys by simply letting at.exe open regedt32 for you.
(PS: If it helps, I do agree w/ you perfectly that that's a pretty crappy password.)
Quo usque tandem abutere, Nimbus, patientia nostra?
If I remember correctly NT drop anything after the first 8 characters so the password is actually "Fgpyyih8"
You do not remember correctly. LM hashes are created by hashing the first seven characters and the second seven characters, and truncating the hashes together. Yes, instead of having to brute force one fourteen character password, you have to brute two seven character passwords, a much easier proposition.
The hashes are created by using DES56 on the password chunks with a known key. In practice, I've used a DVD with rainbow tables and retrieved 99%+ successfully. For those I need 100%, I have a USB drive with a complete keyspace set of rainbow tables. Works everytime...
I once took the time (and CPU horsepower) to generate 64GB worth of rainbow tables. I must've done it wrong, though, because it didn't work on anything. I'll happily admit that I was just puttering around, and probably forgot to set some switch somewhere. Fortunately, I had a server that I didn't need for a couple weeks. :)
-Arthur
Cave ne ante ullas catapultas ambules
you're telling me that my Hotmail or Yahoo! passwords are much more difficult to crack than the Windows one?
No pun intended.
That is actually still a very bad idea from a brute force attack perspective.
Most good brute force attacks will focus on chaining words together and permutating all the 1337speak versions of the passwords. An example is John The Ripper which is rule-based and will therefore crack based on the probability that two characters will be next to each other... and a whole stack of interesting and complicated rules. It can work around deliberate spelling errors and random characters inserted in the middle as well.
Seeing as most IT admins pick dictionary passphrases and convert them to 1337speak, the approach I mentioned above can be VERY fast & effective.
The other problem is that out of the character set (a-z,A-Z,0-9,punctuation) you are using far more punctuation symbols and numbers than what would be expected in a purely random password. Using this knowledge, you can dramatically decrease the brute force cracking time.
I'm surprised people still use passwords. People need to get off their asses and setup public key cryptography for all their authentication.
Or at the very least, turn off LanManager hashes from being stored in the SAM database on the Windows machine (and also disable all protocols which aren't NTLMv2).
Or simply require your users to have passwords at least 15 characters long. There was an article out of MS a year or so ago about how the "password" is dead and that "pass phrases" will take over. Not a very well written article, but it did go over the weaknesses of short passwords, hashes, and rainbow files. They are essentially the same thing, only pass phrases are longer... much longer. Instead of having to remember "HYjK))w!x%" (which, if LM Hashed, can be cracked by a rainbow file in short order) you can remember "This is the passworrd for my new computerr". No one is going to carry a 5 terrabyte rainbow file around to try to crack a password that long. And brute force would take years. Given a few spelling mistakes and a dictionary attack will fail.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Is 53cr3TPa55W@rD a better password than Fgpyyih804423? Why?
It's not a trick question. Can you demonstrate that real security is improved by having a secret string conform to a non-secret policy? Are you sure you haven't got any unexamined assumptions in your reasoning?
You also should think twice about allowing commonly used metacharacters in passwords - dollar signs and asterisks carry some risks, for example, that should be probably be quantified within your computing environment.
In Soviet Russia, you eat hamburger,
In Fascist Amerika, hamburger eats you!
You twits! Nobody will ever find out my password!
So why is this news? Haven't Rainbow Tables been around for several years now? I remember I was looking into them when I wanted to crack my high school network admin's password (turns out I didn't need to, it was 3 characters long).
Hi, There's no need to crack the LM&NT hashes of a password, you can use the hash directly on windows using this tool: http://oss.coresecurity.com/projects/pshtoolkit.htm basically you can impersonate on your own windows machine any user if you have the hash, and then use your Windows machine to authenticate to services using that user's credentials. There's no need to know the cleartext password, unless you explicitly want to know the cleartext password to test it on other services that do not use NTLM authentication.
LM hashes split passwords in 8-letter chunks, and for each of them:
1) the last symbol is removed, so the chunk becomes a 7-character password
2) the password is uppercased (yeah, that's dumb)
and then hashes are calculated for these chunks.
BOTH the LM and NTLM (a much more secure hash) hashes are stored in the registry.
So to get a typical 8-character password, you only need to guess the first 7 characters in uppercase.
After that the more secure NTLM hash is used to guess the case of each character and the eighth character which is missing from LM.
This means that guessing a 16-character password takes at most twice the time than for a 8-char, and not something like 40^8 times as much.
More info here: http://en.wikipedia.org/wiki/LM_hash
if you are already on the local box, then install a keylogger.. why bother trying to crack a database?
Burger without salt = anybody can mug you for your money
:D
Burger WITH salt = You have a full security team recording who comes to visit you, and you have this barrier of protection with reinforced steel bars! PLUS - you have the right to make a call!
See? With salt it's much more secure!
and there's no need to crack the password if you want to connect to services using NTLM authentication: take a look at this tool: http://oss.coresecurity.com/projects/pshtoolkit.htm http://oss.coresecurity.com/pshtoolkit/doc/index.html
power inside l0phtcrack ...
there, fixed that for ya. This was news in 1999, y'all. Seriously, this story is proof that CmdrTaco is posting stories to troll.
3,735,928,559 articles on Slashdot, and "news" is a decade-old dupe.
Just a heads-up to those looking to install it easily: This program is already in Debian, thanks to the work of Adam Cécile (Le_Vert). You can see it on the packages page at http://packages.debian.org/lenny/ophcrack .
|/usr/games/fortune
The LM hash is a old legacy security technology, ~ 20 years old, and like the crypto of its day, single key DES and 384 bit RSA, is weak. It is off by default in modern Microsoft products, where the more secure NTLMv2 is preferred. If you don't know what your policy is, simply use 15 character or larger passwords. The larger passwords disable the LM hash functionality, forcing movement to NTLM. If you use mixed case and add in numbers and special characters, the resulting large passwords are quite resistant to rainbow tables. My passwords are typically ~ 18 characters long. Cracking them with a cracker is goign to be rather expensive.
What are you talking about here? Windows 98? So tell me...You walk up to my computer console, but you don't see the computer. The keyboard is wirelessly connected to it and the monitor cable goes up into the ceiling, but somehow you manage to locate my computer, by following the monitor cable and you discover my computer is locked in a steel rack-cabinet, how do you plan on hacking it? Ok...let me make it simplier...my computer is on the desk, I don't have any devices you can boot from on the computer, because I boot from the network. I have turned off USB and other access points via the bios, which I have locked with a strong password. How is it the 9 year old is going to hack my computer? Oh...wait...even simplier....I setup a strong password in my bios that will be required at power-on...exactly how was it you were going to hack that again? A strong password doesn't have to be difficult to remember...for example: iC-UR~N~ED-ot
It's important to know that I forgot what I thought I knew when I thought I knew it all:Now I don't even know whatIknow.
Actually this doesn't mean you should panic and start using difficult passwords for windows.
This just means you shouldn't use the same passwords for windows as you do for other stuff.
If someone can successfully run 0phcrack on your system (or its lanman hashes) it means they're already in, and they probably already have access to the data they want (can install rootkits, keyloggers etc).
It's laughable to think someone is going to physically bring it to your machine and _bother_ using it without your cooperation. Might as well just boot the "Offline NT Password & Registry Editor" disk.
If the "rules" are no reboot then it's far easier to plug in a USB or firewire device and instantly take over your system.
A cleaner could also stick in a hardware keylogger whilst being so nice as to clean the crud from your keyboard.
Being worried about this is like being worried that someone in your house could take photos of your keys, and make duplicates.
On that subject, if a real snoop is targeting you, with all those high res cameras available, they could in theory take pictures of your keys when they are visible e.g. just before you use them (or if you dangle them about somewhere, on your person, or even in the house but visible from outside) and then get in later with no fuss - no need for the lockpick crap or even bumpkey stuff (bumpkeys don't work with certain sort of locks).
Burglars will just break in.
It's just another rainbow tables program. Yay. It may be better written than some (I don't know I haven't tried it) but it isn't anything new. There are plenty of rainbow table generators out there. The only problem you discover is that they take a shitload of space to get useful results. Also, if you are dealing with LM hashes, as this program is, there's no need. A Core 2 Duo can easily break pretty much any LM password in 24 hours or less.
However it also isn't that useful since as of Windows Vista, Windows disables the storing of LM hashes by default (you can tell XP and 2000 to disable it too if you wish). As such LM tables are ineffective, there's no LM hashes to compare against. NTLM, being a much better hash, is not nearly so easy to generate a hash table for.
>Sorry Jeff, but thats a shit password. If I remember correctly NT drop anything after the first 8 characters so the password is actually
Actually, Unix DES-56 truncated it to 8. But we all use a Blowfish one nowadays (minus the fedora folks who still have not managed to update their glibc...).
Or just force authentication against the MIT Kerberos domain..... Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes. Layne
You can still do this with WinXP, although i find it much more useful to open cmd.exe, more options that way
No one is going to carry a 5 terrabyte rainbow file around to try to crack a password that long.
At least not for a couple years until 5TB hard disks are available.
Give it a year and someone will come up with a clever plan to decypher it again. Don't ask me how, our cypherguys are elsewhere (and I refuse to talk to them, they're creepy!). Some statistical imbalance for this or that if this or that structure is in your sentence, or a flaw in the algorithm because you now have a larger sample to work with than with traditional passwords of 5-10 characters length...
It's always been a race. Don't think one side can win forever.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Pretty similar name to L0phtcrack... any relation? If not, you'd think they would be wary of looking like they're trying to play off LC's success. Ahh regardless, reading up on L0pht brings back a lot of memories.. ;)
technically speaking you can still crack a black password
That's African-American password, bigot.
Right! Even though it conforms to a supposedly "better" password policy, it's more crackable than something that didn't conform to the policy.
Too-strong policy can easily reduce security - the best example being the sticky note under the keyboard, because a sysadmin set a policy so strong that Joe Sixpack can't possibly remember his password.
If we all use the same policy it makes things much easier for the black hats. So, anybody who is following a recipe from a book (instead of thinking really hard about their unique environment and user base) is not practicing good security.
I have CheetOS 98, you insensitive clod.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Good passwords are half of the equation. If the hacker knows your user name then the hacking program only needs to solve for the entropy (cipher quality) of the password (of the hash). This is given by an equation based on the number of characters you can use in a password and the character set base. So let's say you are using a base64 character set. That gives us:
6 bits per character = (ln 64) / (ln 2)
This is because there are 64 possible ascii values per string character in a base64 character set. So for example, creating a random key string to be used in encryption with a base64 character set, you would require the following number of characters:
A 128 bit encryption key: 128 / 6 >= ~22 characters
The problem here is that Windows only allows passwords that are 15 characters (I don't immediately know the base character set windows uses without looking it up). But the entropy to solve for with Windows passwords is probably much less. It is best if your user name is something that isn't easily known. I suppose a 15 character base64 random username and a 15 character base64 random password would be about the best you could get under windows. However again, you need to release the username "publicly" sometimes, so again we are stuck.
To prevent attacks against passwords, the authentication or encryption libraries need to be able to use failure-delay schemes. However that won't work for physical access to the machine in which case all bets are off anyway. So if Ophcrack needs physical access to the machine, why exactly are we discussing this anyway?
How on earth is this news, I have done this for at least a couple years, and others have one it for years before me. Cracking windows passwords is soooo easy. I even have my own web cracker for MD5 hashes that I wrote myself for my first active webpage(its code is downright ugly and in ASP and Java with MSSQL). I have the Rainbowtables (64 GB binary not decimal) to crack any (99.95% success rate) Windows LM password of any length (due to how windows hashes only sets of 42 bits (7 chars) for each password. and no you may not have the URL or you would overload my poor little server's bandwidth, but probably not my cracking power. anyways 2^42 * (42+2^8) = 1310 TB = space to store an array of all 2^42 possible 42 bit passwords and their 8 byte hashes. and this is not an unfeasible number for a distributed project that offers instant lookup of ANY password. oh also this number would be much smaller due to collisions where you only need to store one of the plaintexts not both because both passwords would work. by comparison, if you take sqrt(mass Earth) in grams of carbon, the number of atoms you have is the number of possible md5 hashes assuming no collisions.
I have to use a frigging 16 character admin password (that my company's policy says I have to change every 30 frigging days)!
That would be a great password, except:
md5sum("This is the passworrd for my new computerr") = fb7393356dd5f5e6d3909e06bf64c91e
md5sum("hello12") = fb7393356dd5f5e6d3909e06bf64c91e
Better luck avoiding an unintentional collision next time.
Badass Resumes
Hmm... it seems to me that the pass phrase idea wouldn't be that much more secure should cracking utilities be crafted to them. English words and phrases aren't terribly random. They compress very well after all. So it doesn't seem like you gain any entropy from a pass phrase, just length. To crack a pass phrase one could use an intelligent dictionary search that exploits the rules of grammar (subject, verb, noun) combined with word and letter frequencies, and with some spelling variation. Pass phrases aren't inherently more secure than passwords, just longer. It's possible that pass phrases could serve as mnemonic devices, thus allowing a user to remember a secure pass phrase more easily than a secure password, but I have my doubts.
Just in case I haven't explained my point very well, here's a more mathematical example. A 16 character alphanumeric password has a total of (26*2 + 10)^16 ~= 2^95 possible combinations. The average person uses something like 2,000 words in a given day (and only knows something like 15,000). A 9 word pass phrase could then be something like 2000^9 ~= 2^98 possibilities. That's better than a 16 character password, but it assumes that the 10 words are randomly picked and unrelated (and spelled perfectly). By mixing in misspellings you might gain, say, 100 possibilities per word, but it's also likely that a few of the words will be "the", "a", or "I". The rest can be searched based on usage frequency and word order. It makes cracking more complicated, but it probably wouldn't add significant time to a bruteforce attack. Unless, of course, pass phrases are a mnemonic device that let people remember something really long and random (hence with a lot of entropy).
Will someone please tell me how these fucking tags, or any of the other letsshoveanentiresentenceinonetag tags contribute in any meaningful way to reading Slashdot? You used to be able to turn this shit off. Click on it, and it doesn't even link to the stupid post that was tagged. Waste of fucking time. Every time I visit slashdot, I ask myself louder and louder why, because shit like this makes it more of a problem than a solution to anything.
Or you can carry around a 256 MB flash drive, take the hashes home, and crack them there.
First of all, this is specific new to windows (I am not a 100% windows hater) /etc/password, but in a special hidden protected file
1) Unix derived stored passwords use salt, windows doesn't, which instantly makes them far more secure.
2) Linux no longer stores the main password in
Using "funny" symbols in your passwords do help, the chances are people will use rainbow tables over brute force to crack a password, and these generaly start with known words, then random letter, ending in random symbols and such likes, meaning it will take longer to crack your password.
Assuming a person can't get inside your computer, it is possible to secure a unix derived machine.
1) Password protect the BIOS, and make the only boot device the main hard drive
2) Password GRUB, or whatever boot loader you are using, so they can only access your OS, and not as root
3) Password protect your user account, and don't allow root login, just for good measure
4) Use extra login security, like an external key device and biometric scanner, pretty rare, stops agains key loggers
5) Use an encrypted file system and swap space, if you really don't want people to get in (even if they steal your hard drive)
6) Put an electro magnetic scrambler in the case, so when it is opened without the key it wipes the entire hard drive (assuming you keep backups)
Eh?
> ttyp5 zhengyi@oracle.local.lan:~
> 0 14:11:43 504 $ echo "This is the passworrd for my new computerr" | md5
fb7393356dd5f5e6d3909e06bf64c91e
> ttyp5 zhengyi@oracle.local.lan:~
> 0 14:11:59 505 $ echo "hello12" | md5
39e8713c209ccefc6ddfafa6aedde5d1
(FreeBSD 6.2 box here; md5 came w/ the system...)
I'm not sure I entirely agree with you. I would concur that if the pass phrase were written in sentence for with proper spelling, then yes, it would be easier to brute force then a random string of characters of the same length. Such an engine would have to be significantly more complex though, and there is no way to identify the number of words. So if we were talking about a 9 random word pass phrase, with an average of 100 possible mis-spellings per word, you are looking at 200,000^9 possibilities (~5e10^47) as opposed to a your rough estimate of 2000^9 (~3e10^29).
Heck, lets figure you can stick some grammar rules in there to bring the average likelihood of each word down to 1 in 500. Even then you are looking at 50,000^9 (2e10^42).
If you are using MD5 for encryption (32 characters, 1char = 2Bytes, 1 Byte = 8bits, 32 Char = 512bits) that means 64,000,000,000,000,000,000,000,000,000,000TB of space. Although I'd venture a guess you'd start running into key collisions long before you made it there. Even then, to have every valid seed for every possible key would be like 512! bits. And 512! is a huge freaking number.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Use foreign language characters to give them a headache. We in US have a 26 character alphabet with rare use of accents and other modifiers so it is easier for them to to crack at these English based passwords. I use Japanese on my home system and they use a larger multibyte per character so that they need to know I'm using another language for the password first. Try using most western European languages will throw them off like using esset from German alphabet or accent marks on the letters.
Unless something has changed dramatically since the last time I researched this topic I'd say that 15 gigs is being extremely generous. I'd say closer to 60 gigs on average.
The problem here is that longer passwords will not help at all.
A complete rainbow table contains an example of EVERY possible hash for the given hash length. Therefore if you are using MD5 hashes that are 32 hex chars long, the size of your hashtable is going to be whatever is required to store every possible hash.
Then all that is needed is to look up *A* string that results in said hash. This may not give you their password at all, but rather *A* password that will hash to the same result, therefore allowing you entry anyway.
Now, usually the collisions of a text string end up being something unprintable or something totally off the wall, so the actual password is typically found first when brute forcing. But this is not brute forcing, this is a rainbow table!
I thought that was a union for the people that made trousers for plumbers and construction workers...
Rich
If someone has enough access to steal the LM hashes, couldn't they just steal your private key as well? How is that an improvement? At least with a hashed password file, they'd need to take the additional step of cracking the hashes.
Salty burger lands McDonald's employee in jail
You messed that up. md5 is 128 bit. 1 char = half a byte or one nibble. 32 char = 16 bytes = 128 bits. Still a huge search space though.
> Is 53cr3TPa55W@rD a better password than Fgpyyih804423? Why?
/usr/bin/dict + lots of foreign language dictionaries, names, etc.). I've seen some that even contained things like "keyboard runs" (e.g. shift+12345 -> !@#$% or qwertyasdf). So you want to avoid those.
First, there's an issue unique to LTMN passwords where they chop the password in two and hash each part separately. But I'm going to focus on the "four food groups" for a good password and why you use them.
You see, most password crackers have a few modes:
* Crack via a word list
* Crack via word list + rules
* Brute force all passwords with some character set of up to N characters
You want to make sure that your password is hard to get, so you make sure it's not something that'd be in a word list, even if you apply simple rules like "l33t sp34k" and that it's not a word in any language.
What kind of simple rules? Well, I already pointed out l33t, but you also have to remember that those rules are applied to word lists (e.g.
Then you get down to character sets. Most passwords are all lowercase letters. So that's the most obvious thing to brute force, followed by lowercase + numbers. There are four main "food groups" as far as password crackers are concerned: lowercase, uppercase, numbers and symbols. Also, password crackers try shorter passwords before longer ones, so longer is better.
Therefore, to ensure that your password takes as long as possible to crack, you want it to be composed of all four character sets and to be as long as possible. The reason for this is because they'll try to crack the easy passwords before the hard ones, and you want one that will force it to waste a lot of time guessing so that they'll give up.
Don't get me wrong: there are many attacks where your password will be irrelevant because they'll hack in an easier way. Or perhaps they'll crack someone else's password instead of yours. But if you want your password to last, you want to make up your own unique rules to compose something with a good mix of uppercase, lowercase, numbers & symbols that doesn't look much like a word.
My standard example is to suppose that I took a phrase like "Land ho, matey!" and reduce it to a nice 8 character password like L&h0m8y! (L& -> land | h0 -> ho | m8y! -> matey!). Now don't use that. Come up with your own rules. And no, I'm not contradicting myself--that's just not likely to fall in a word list, even with rules applied to it. They usually don't condense passwords out of that many words, especially not with that many substitutions.
But don't take my word for it; pick your own rules and crack your own passwords.
A long time ago, I had read tons of worthless and contradictory advice and I didn't know who to believe. Then I learned to use a password cracker and I set it loose on my own passwords. That's how I know that my advice is good: because I did empirical tests on my own security.
I encourage everyone with an interest in the subject to attempt to reproduce my results. There are too many people who simply repeat advice they thought sounded good and FAR too few who can advise you based on their own experience.
And the worst part is I wrote 128b the first time, then double guessed myself and wrote out the math (while screwing up the char to byte size).
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
A rainbow table is a pre-emptive brute force. You can do the brut force work at your leasure, then when you need to crack a LM Hash encrypted password, you just need to find a matching key in your table and enter the seed that generated that key. But the specific problem in the Windows case is the way LM Hash works. As soon as your password hits 15 characters though, the encryption runs through Kerberos. And I have not heard of any existing rainbow table solution to cracking a Kerberos password. Then again, I've been out of the security field for a year or two now, so I may have missed that memo.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
See: http://support.microsoft.com/kb/310105/
maybe they can suggest one for me.
The rest of us don't need keys...
Or passwords. (lol)
Truth isn't Truth - Guliani
I didn't calculate in variations of words and misspellings because the grammatical and frequency components would still dwarf it. (And even misspellings are somewhat predictable.) With pass phrases the number of possible "phrases" is huge, but the number of likely phrases is much more manageable. English text (and probably text in other languages) compresses very well, something like 85% - 95%. A brute force algorithm could simply decompress random text of the appropriate length. Something like: random string --> decompression --> longer string of characters with English-like characteristics. Here's an example:
So if a 9 word pass phrase has an average word length of 5, plus one for punctuation/spaces, then the pass phrase would be approximately 54 characters long. If that's compressed to 5% - 15% of it's original size then the compressed text would only be 2.7 - 8.0 characters long. So you only have to search a key space of between 2^8 and 2^24. Therefore, in this case, the pass phrase would be far easier to brute force, unless it was extremely random (high entropy --> lousy compression but better encryption). The problem, IMHO, is that people aren't good at being random, and have a lot of difficulty remembering truly random things. It doesn't matter if you make people type 16 characters or 54 characters, if it's not random then it will be easy to brute force.
from a prompt, using a floppy, that are present in every version of windows since 3.1 that I own; I don't have vista.
If you can get a login prompt on a remote box, they work there too.
And, there are hidden logins that always work, and have default passwords; if they're different, that means you ARE being investigated...
The nice thing about open code is that no one can slide in stuff like this...
Actually, all you need is the password hashes. You don't even need to crack the password.
:)
Example:
When you go to login to your server, you type your username and password into your machine and click 'submit'. Your machine sends a request to the server to login (no credentials are sent). The server responds with a nonce, (nonsense data/random garbage). Your PC takes the password you typed in and hashes it, then it uses the hash to encrypt the nonce it received from the server. It combines the encrypted nonce with the username and transmits it back to the server. The server does a lookup on the username, takes its private copy of your hashed password (stored on the server) and uses that hash to decrypt the nonce it sent you, then compares the decrypted nonce to the nonce it sent out to you. If it matches, you must have typed in the correct password and you are issued an access ticket; your actual password is never sent across the network.
The weak spot is the hash. If I have gathered the hashes from the server, I do not need to go through the trouble of cracking them. I have written a custom login tool that all you do is type in the username. The program looks up the hashed password associated with the username and uses the hashed value to encrypt the nonce.
At this point, it doesn't matter if your password is 1 character or 14 random characters, if I have your hashes, you're toast. Cracking the passwords is simply an academic exercise at that point.
Regards,
Joel Helgeson
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
Just repeat your normal password 3-4 times to make it long enough that ophcrack can't break it.
Can anybody tell me why Vista STILL doesn't salt their passwords?
/screw backwards-compatibility -- can you just stop sucking for once?
There's a problem with your theory though. Password encryption is one way. It is lossey by design, and you will not be able to determine the length. Wether you type in 4 characters, or 40,000 characters, the encrypted value will only be 128b long (or how ever long your encryption system is geared around). We're not working with a phrase that ever needs to be decoded like you would with a communication.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
This tool's been around for well over a year. I remember getting pissed off that it had taken over as the number one result on Google. All that work for an original name, and someone comes along and uses it for this.
You don't need to know the length though. Just like traditional brute forcing, start small and work your way up. Start with decompressing an 8 bit sample (or whatever), then move up to whatever is practical. Decompressing x random bytes won't always result in an output of y bytes, but as x increases y should increase as well (in general, specific cases are unpredictable). I defined the length so I could estimate the keyspace that would need to be searched before a match would probably be found. BTW, (just a semantics note) encryption does let you know the length of the clear text within one block size (128 bits for example). Hashing always results in the same size output.
I see there is a commercial version that supports Office documents, but how about a free version? Also, could this be used with AES encrypted RAR files perhaps?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Whoops, my "home user" perspective is showing.
BitLocker is also available in Vista Enterprise(only sold through volume licensing), not just Ultimate.
I'm not sure I follow ya. If I grab an md5sum of a 17GB DVD rip, it will be 32bytes long. If I grab an md5sum of "Hi", it will be 32bytes long. Looking at an md5 hash, there is no way to determine the length of the seed (so far as I know). The LM hash does present this issue to an extent though as it is two 7 character blocks hashed. In the case of LM, yes you can determine if the password is 0-7 or 8-14 characters in length. But, as soon as you go to 15 character, Windows will not use LM to encrypt your password. So you will not be able to get the length of the passphrase, even to a block length, once it is longer than 14 characters.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Hashing works like you mention. It takes any length input and generates a fixed sized output. There are two major types of encryption, block and stream. Stream encryption always generates output the same length as the input. Block encryption requires that the last block processed be padded so that it has a block to work with. In either case the original length can be determined (to within a block size, so 128 bits for example) by the length of the cipher text. Hashing is one way, used for file and password verification. Encryption is reversible, so it can't discard data to generate a fixed length output. So, as I mentioned before, it's a semantics issue since encryption != hashing, though they are similar.
As for brute forcing, adding an additional character increases the keyspace geometrically. So it doesn't take much longer to bruteforce all 1 - 9 character passwords than just 9 character passwords. The method I describe for bruteforcing pass phrases is essentially traditional bruteforcing with one extra step. So it isn't necessary to know the length of the original pass phrase.
I love how FUD articles get posted on the front page, but they would never post something with actual content like this:
Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes
Why on earth would we be going over a reversible encryption in a conversation about passwords and pass phrases? I am familiar with the difference. I was avoiding that part of the conversation because I assumed that anyone looking at encrypting passwords/phrases would know that you do not want there to be any possibility of decrypting the value. Hashing is a subset of Encryption. Saying Hashing != Encryption is like saying Car != Vehicle.
You keep jumping back and forth here. If you are going to brute force, then no, going 1-9 is not that much bigger than just 9, but if you're going brute force, then your English logic is not going to help you. And if you are trying to use the logic, you are going to be hampered by not knowing the length of the string. The other problem with that statement is that we aren't talking about 1-9 character passwords. We're talking about 15-100+ character passwords. 256^9 is a huge freaking number (close to 500 quadrillion?), but 256^100... you're talking about 6.6e240. Even if you figure your logic can cut the character count down to say 30:1 (mostly letter, slight possibility of upper case, etc...) you're still looking at 5.1e147 possibilities. Heck, lets toss in another 50% reduction for your English logic, even with 15:1 for each character you're looking at over 4e117 possibilities.
The point remains, if you are using Windows, and you want the most secure* password you can get regardless of your PC's or network's configuration, make sure your password is at least 15 characters long. If you do that, these rainbow files will not crack your password. And any attempt to brute force your password, including those attempting to apply pass phrase logic, will take such an inconceivably long time** that they are not a primary security concern***.
*most secure does not imply that the password is actually secure, just that it affords the most security as far as default
password protection in Windows is concerned.
**obviously the caveat here is that if someone has your security data off site and has unlimited time and sufficient processing power, it is possible to crack. But with solid network security and expiring passwords, the likelihood of your password being cracked before you change it again is slim.
***Once again, not saying that the password is uncrackable, just that at that point there are other weaker links in the chain.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
I've found writing password crackers also provides insights. They are useful for auditing your enterprise, for converting hashes without forcing users to do mass password reassignments, and for recovering lost passwords from systems you don't want to shut off for whatever reason.
For example, when you write a cracker you don't follow the same algorithm everyone else does. That would be pointless, since you could just use John or pandora or whatever. I haven't written one for a few years, but I'll tell you what I learned the last time around.
Your post presupposes that the programmer who wrote the crack makes the same distinctions you do about separating characters into groups. I certainly don't code that way. I assume all the printable ascii characters can occur in a password because it makes the code easier to write. Using more or less of them has no effect on runtime, it just makes it take longer to generate the rainbow tables, which is essentially a one-time job and I don't care if it takes six months (it took about a week for the last crack I worked on, which was a pretty simple XOR based thing a widely used email client uses to save POP passwords). The order in which passwords are tested, however, is indeed based on some simple rules (some gathered from others, some invented by myself on the spur of the moment) and the individual tests run very very fast.
If you *allow* the user to use more characters (including upper/lower case, numbers, and specials) you've increased the space that may need to be searched. If you have smart users you have just made the job harder. But then, if you restrict the password space by requiring certain combinations of certain numbers of characters you just made the crack much easier. If I were writing a cracker today, I'd absolutely assume that I didn't need to test for anything listed in cracklib, and I'd test the strings that fit your criteria FIRST, not last. I'd specifically look in the space of all possible passwords for things that embedded leet-speak substrings I could find in a dictionary of short (eight char or less) words, too.
Incidentally, unless I've audited the code (which I don't typically have time to do in such situations) I always assume that programs like Lophtcrack and John the Ripper are secretly emailing (or otherwise passing on) the password and host information to their original authors or distributors, or installing backdoors, or whatever. It pays to be a little paranoid. I only use code like that when I can physically isolate the cracking host from all external connectivity - for example, when I bruted a bunch of MD5s with john, I built an "expendable" host, moved the password file on to that host, unplugged the network, ran the cracker for six weeks, and moved the output with a 3.5 floppy... after which I reformatted the hard drive on the expendable PC.
Educating the users, and restricting everyone (including yourself) to the least possible access required to perform the job, is the one recipe that works. The other recipes just make your passwords more predictable.
i must be new here, but i've never found links to /. comments before this day
probably i haven't search hard
i'm speaking about "PassTheHash toolkit" keyphrase btw
I choose friends for sigs
I had troubles with logging in to sf several times since I always had to change my easy password for unimportant sites which usually contains special chars. :)
Thanks to recovery system
I choose friends for sigs
Nope, "we" aren't. I'm talking about 15-100+ character passphrases compared to standard sized passwords. If we were talking about 100+ character passwords then nothing that I've mentioned would even come close to making it crackable. Proper passwords have a fairly high entropy, pass phrases don't. That's the difference and that's why what I'm suggesting would probably work. I realize that you already understand the difference, but you're using the terms synonymously, and it's a little hard to discuss the differences between the two unless we use different terms for each.
With the exception of my hash VS encryption triad I haven't been jumping around. My original post was about the fact that pass phrases don't inherently contain more entropy than passwords, and as such could be bruteforced. My later posts entail a theoretic way that such a bruteforce engine could operate. It would be stupid to bruteforce 30+ characters of anything using the traditional aaaa, aaab, aaac approach. A keyspace of 256^100 isn't even worth considering. Because they are longer, pass phrases seem more secure at face value. But English is very low entropy. Compression is not a 50% reduction, the human brain has few problems decoding something like that. Fr exmp ths sent cn b read ez. With a more standard 85% compression that 100 character pass phrase becomes only 15 characters (still difficult, but not impossible with current technology). Now why does this matter? Well, what if we try to brute force the compressed version of the text? That's what I'm suggesting. I am not suggesting brute forcing the fairly long pass phrase, just the short compressed text. "This is my really, really, really long pass phrase." may not be easy to brute force directly (256^length), but a 10 (or whatever it may be) character compressed version is bruteforcable (256^10 = 2^80). Knowing the length of the pass phrase isn't necessary. The reason I'm stating the length is to illustrate the the keyspace isn't something like 256^100.
I don't even use a multi-user OS, so there are no hashed passwords on my system. I'm speaking in general terms. Also, the storage of lanman hashes can be disabled in the registry, so a 15+ character password isn't necessary (though it is more secure). Rainbow tables will still work, but I wouldn't feel safe against them at 15 characters.
return ++i+++i++ ;
They told me that the result is totally unpredictable.
http://ophcrack.sourceforge.net/tables.php: LM Hashes with 33 special chars (WS20k tables)
This table set cracks 96% percent of LM Hashes of passwords of length up to 14 characters made of the following characters :
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&' ()*+,-./:;?@[\]^_`{|}~ (including the space character)
This table set is available from Objectif Securité and from Forensic & Security Services in the US.
I lost my sig.
Sure, you need physical access for the one-touch LiveCD.
The key point for real security, however, is the speed. Obtain the SAM anyway you manage, and you'll know most of the passwords in a very short while. I'm sure this can come in handy even without physical access.
Say, an old hard drive junked by the company. Maybe not an important machine, and nobody cares if you have physical access to it or not. But if you get some usernames and passwords off it, chances are you can use them elsewhere.
I lost my sig.