I’m confused. This post says that crypt is limited to 8 character passwords, but the recovered password is 22 chars long. Wouldn’t it have been recovered much sooner?
Interesting to see that file, where e.g. a user’s username is ken and the name field shows & Thompson. Apparently that’s a substitution marker: https://man.openbsd.org/passwd.5
The full name may contain an ampersand (‘&’), which will be replaced by the capitalized login name when the gecos field is displayed or used by various programs such as finger(1), sendmail(8), etc.
Hm.
If I was Ken, I’d be grumpy at least, having to think of another password at the age of 76 ;) - and I cound not even pick another chess move, because these will be added to wordlists in no time.
I’ll be honest, I never in 100 years thought that my thread on TUHS would have such a wide ranging interest. The fact that it has hit ars technica and the reg is pretty damn staggering.
Yeah, not at all. Unsalted hashes, though, so at least it’d produce a rainbow table holding every password you’d tried (to be applied very cheaply to other passwd files).
I’ve been seeing headlines here and on the orange in the past couple years about spending $75.00 USD with AWS to, I can’t recall, crack anything or whatever. Wish I could look it up but no search-fu this morning. Do you know what I’m referring to, and if so, why or under what conditions it’s possible to do that (compared to spending four years like kqr exclaims above)? I get that increasing character set size is a building-up of the underlying mountain of math. Is that curve (of increase of time per additional character to get your three-letter thingies) exponential or logarithmic or what?
Reason I’m asking is because “plenty of passwords” are “pretty long.” (Scare quotes to indicate my stupidity.) Does having an 8+ char password “pretty much preclude” bruteforce attacks? Or is it possible that some combos are “at the front of the rainbow table” and get cracked anyway? (I know the table is built as you go along, but I mean like, at the beginning of “the combinatoric pattern” or whatever that produces the table, the same randomly selected randomness “by chance” occurring in both the password generator and the password cracker or whatever…)
I once had the opportunity to use john on a real-life computer system actually in use today that was, as john ironically notes in beginner documentation somewhere, “so ancient that anybody could go and view /etc/passwd” because no shadow file. I was “pretty surprised” how long some of the passwords took, and some were never cracked. I wasn’t using GPU acceleration, by which I mean a $1,000 AMD/NVIDIA thing. But it still had a baked-in GPU, obvo. To no avail (after a couple days or more, can’t remember). My question here is: does crypt(3) have vulnerableness compared to whatever the OpenBSD hipsters use nowadays due to its using some older curve, or lower SHA, or whatever, or something else? If it does, how come it’s just the character set blowing up that concomitantly explodes the time it takes for eg hashcat to win?
In the dark ages of the pre-WWW ‘90s and earlier (I wasn’t alive), I’m guessing it took a certain amount of computation to generate passwords, which I’m guessing now is exponentially exceeded like everything in computing by the amount of computation it takes to do the same task, on a new curve, with a new CPU, or whatever. So why does it (still) take so long to crack some “sufficiently large-charsetted” crypt(3) thing…? When you say “bruteforce takes forever,” I’m like, lacking some context. If you can’t tell. :)
Brute force still takes a long time on obsolete algorithms, long enough to be infeasible for many cases. However modern algorithms strive for universally impossible, not merely infeasible.
Is that curve (of increase of time per additional character to get your three-letter thingies) exponential or logarithmic or what?
Exponential.
Does having an 8+ char password “pretty much preclude” bruteforce attacks? Or is it possible that some combos are “at the front of the rainbow table” and get cracked anyway?
Common passwords and patterns definitely get checked first. For example, “password” is 8+ chars, but hardly secure no matter how strong an algorithm you use.
whatever the OpenBSD hipsters use nowadays
As far as I know, OpenBSD still uses bcrypt, an well known and widely used algorithm from 1999.
always salts passwords, so rainbow tables don’t work
takes a ‘work factor’ parameter - increment this number to double the processing required. I’m 95% sure you can increase this without having access to the original password.
Cool! This was an awesome little tidbit of history :)
++, Ken!
I’m confused. This post says that crypt is limited to 8 character passwords, but the recovered password is 22 chars long. Wouldn’t it have been recovered much sooner?
I was confused by this too. I think the part before the colon is the hash, and the part after is the decrypted password.
It is clear if you follow the link to the
passwd(5)file in the post - yes, the part before the colon is the hash :^)Interesting to see that file, where e.g. a user’s username is
kenand the name field shows& Thompson. Apparently that’s a substitution marker: https://man.openbsd.org/passwd.5I had no idea.
Yup - on OpenBSD, you get emails from Charlie Root! ;^)
master.passwd(5):I also use it for accounts on my machines.
I wish Linux used the same format :^(
Oh! That clears up my second question too, which is “why would it take so many characters to describe a single chess move”. :-P
Why is that?
Because of how hashcat works. Something like: towards the end, it can’t create enough work to fill the GPU.
They specifically point out why in this FAQ entry. If memory serves JtR jumbo does a similar thing.
Ken, if you’re a lobste.rs user, we’d love to hear you weigh in. :)
Looks like he responded in the email thread: https://inbox.vuxu.org/tuhs/CAG=a+rj8VcXjS-ftaj8P2_duLFSUpmNgB4-dYwnTsY_8g5WdEA@mail.gmail.com/
ken’s response, “congrats”.
https://inbox.vuxu.org/tuhs/CAG=a+rj8VcXjS-ftaj8P2_duLFSUpmNgB4-dYwnTsY_8g5WdEA@mail.gmail.com/
Hm. If I was Ken, I’d be grumpy at least, having to think of another password at the age of 76 ;) - and I cound not even pick another chess move, because these will be added to wordlists in no time.
Well, the he doesn’t need to worry. He can get in without a password at all.
This article was amazing
I’ll be honest, I never in 100 years thought that my thread on TUHS would have such a wide ranging interest. The fact that it has hit ars technica and the reg is pretty damn staggering.
You’re the one behind this? Mad props
no, I just started the original thread :)
You shoulda left me sooo impressed, don’t let the truth get in the way of a good story ;)
Great story. For those not subscribed, the TUHS mailing list is full of gems like this.
Thanks!
Wait, does 2^7^8 actually take four years on modern GPUs? Makes sense, but still longer than I expected.
Brute force is slow. That said - 400 GPUs could do it in 3.65 days, and you could rent that easily enough.
Even if you get them for $1/h that would not come very cheap.
Yeah, not at all. Unsalted hashes, though, so at least it’d produce a rainbow table holding every password you’d tried (to be applied very cheaply to other passwd files).
I’ve been seeing headlines here and on the orange in the past couple years about spending $75.00 USD with AWS to, I can’t recall, crack anything or whatever. Wish I could look it up but no search-fu this morning. Do you know what I’m referring to, and if so, why or under what conditions it’s possible to do that (compared to spending four years like kqr exclaims above)? I get that increasing character set size is a building-up of the underlying mountain of math. Is that curve (of increase of time per additional character to get your three-letter thingies) exponential or logarithmic or what?
Reason I’m asking is because “plenty of passwords” are “pretty long.” (Scare quotes to indicate my stupidity.) Does having an 8+ char password “pretty much preclude” bruteforce attacks? Or is it possible that some combos are “at the front of the rainbow table” and get cracked anyway? (I know the table is built as you go along, but I mean like, at the beginning of “the combinatoric pattern” or whatever that produces the table, the same randomly selected randomness “by chance” occurring in both the password generator and the password cracker or whatever…)
I once had the opportunity to use john on a real-life computer system actually in use today that was, as john ironically notes in beginner documentation somewhere, “so ancient that anybody could go and view /etc/passwd” because no shadow file. I was “pretty surprised” how long some of the passwords took, and some were never cracked. I wasn’t using GPU acceleration, by which I mean a $1,000 AMD/NVIDIA thing. But it still had a baked-in GPU, obvo. To no avail (after a couple days or more, can’t remember). My question here is: does crypt(3) have vulnerableness compared to whatever the OpenBSD hipsters use nowadays due to its using some older curve, or lower SHA, or whatever, or something else? If it does, how come it’s just the character set blowing up that concomitantly explodes the time it takes for eg hashcat to win?
In the dark ages of the pre-WWW ‘90s and earlier (I wasn’t alive), I’m guessing it took a certain amount of computation to generate passwords, which I’m guessing now is exponentially exceeded like everything in computing by the amount of computation it takes to do the same task, on a new curve, with a new CPU, or whatever. So why does it (still) take so long to crack some “sufficiently large-charsetted” crypt(3) thing…? When you say “bruteforce takes forever,” I’m like, lacking some context. If you can’t tell. :)
EC2 offers GPUs for 5c per gb of ram per hour. $75 would get you 1500 hours of GPU time.
Brute force still takes a long time on obsolete algorithms, long enough to be infeasible for many cases. However modern algorithms strive for universally impossible, not merely infeasible.
Exponential.
Common passwords and patterns definitely get checked first. For example, “password” is 8+ chars, but hardly secure no matter how strong an algorithm you use.
As far as I know, OpenBSD still uses bcrypt, an well known and widely used algorithm from 1999.
Thanks!
bcrypt is still quite good - features include:
Depends on what’s on the other side of the password, doesn’t it? For some passwords it could be a bargain!