Ars was briefly hacked yesterday; here’s what we know

Readers, please change your passwords.

Read the whole story

 

[huxley]

El Chupageek[/url]":t59c3leu]

foobacca[/url]":t59c3leu]

bthylafh[/url]":t59c3leu]

JGJones[/url]":t59c3leu]Folks using randomly generated passwords via password managers - why limit yourself to 32 characters?

Because lots of websites have a limit on how long your password can be. My natural gas utility, for instance, limits me to 10 alphanumeric characters. Unless they've changed it recently, Microsoft limits us to 16 characters.

If passwords were limitless, you'd have some asshole uploading hello.jpg or a copy of War and Peace as his password.

And when you use a good password hashing algorithm, very long passwords can be used to cause a Denial of Service attack - such as this one fixed in Django (and ars coverage ). Django was fixed by making it refuse to accept passwords longer than 4096 bytes - which is more than long enough for me.

That really should be "Fixed" - the problem still exists, it simply takes more requests to exploit. Not an impractical number more mind you - you need to increase your requests by a factor of a couple hundred, but that's still super cheap. If they have proper flood control in place they can probably prevent those attacks by detecting the increased request rate and blocking, but very few companies do this well.

The problem with expensive password hashing is that it creates an inherent asymmetry between the cost to make a request and the cost to process it, which is a scenario that enables easy DoS. Posting a username/password takes an incredibly small amount of bandwidth, CPU, and memory for the attacker, but an exponentially larger amount of CPU and memory for the processor. Its just an inherently flawed idea, and the Django modification doesn't fix it, it simply makes the attack something slightly less than trivial

The 4096 character limit was a temporary fix that only existed for Django 1.4.8/1.5.4, the password hashing algorithm was improved in Django 1.4.9/1.5.5 to avoid both the limit and the denial-of-service via password hasher (all that took place between September and October 2013, we're now on Django 1.7.1)

 

[Bengie25]

Pluvia Arenae[/url]":eim3hmf1]

pqr[/url]":eim3hmf1]

Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.)

He didn't assume the salt is unknown. What makes you think that he did?

Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

 

[David Crowell]

I don't re-use passwords, so I'm good. I did go-ahead and reset mine here, as I wouldn't want someone to ruin my stellar (cough) reputation here.

 

[pqr]

Bengie25[/url]":r0rgirte]

Pluvia Arenae[/url]":r0rgirte]

pqr[/url]":r0rgirte]

Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.)

He didn't assume the salt is unknown. What makes you think that he did?

Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

It all depends on what you call effective speed. In his terminology lack of salt means you can guess at all accounts simultaneously. Relative to that salt is 1/Naccount penalty (not counting you also lose rainbow tables). I only care for targeted attacks in which case salt does not slow down my adversary (rainbow tables impractical for long passwords).

But as I wrote already for 12+ char random passwords, even if alphanumeric only, this leak is nonissue. I am not changing mine.

 

[Gern Blaanston]

So far, all the discussion has revolved around the good/bad points of MD5. And while it's all quite interesting, I find the first sentence of the article more troubling:

"an Internet intruder gained access to one of the Ars Web servers"

These intrusions seem to be becoming more common and there really seems to be a systemic problem of people not taking security seriously (despite paying lots of lip service). Don't get me wrong, strong encryption on your database of user passwords is a very good thing. But not letting people get to that database in the first place is, in my opinion, even more important.

 

[cheriff]

When the article states that payment info was not compromised, does that mean for sure nothing at all?

On the account settings page I see my credit card type and last 4 digits being displayed to me. Not that this is any great secret in and of itself, but I'd still appreciate knowing whether this redacted payment info is in the same database as the possibly compromised one.

At the very least I know which statement to keep a closer eye on, just in case.

 

[dangoodin]

pqr[/url]":2qx00slk]

Bengie25[/url]":2qx00slk]

Pluvia Arenae[/url]":2qx00slk]

pqr[/url]":2qx00slk]

Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.)

He didn't assume the salt is unknown. What makes you think that he did?

Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

It all depends on what you call effective speed. In his terminology lack of salt means you can guess at all accounts simultaneously. Relative to that salt is 1/Naccount penalty (not counting you also lose rainbow tables). I only care for targeted attacks in which case salt does not slow down my adversary.

Salt prevents attackers from cracking hashes in bulk. Instead, each hash must be cracked one at a time. Stated another way, if the attacker cares only about obtaining pqr's password, salting doesn't slow things down at all. But if the attackers are interested in obtaining all or most of a breached site's users -- as I submit most attackers are -- salting drastically slows things down. This is what Jeremi meant. Hence there is no 'salt' mistake."

 

[Carbon Fibre]

Changed. LastPass bit buggy lately with auto filling and auto generating passwords lately. Thanks.

 

[Devin]

Thanks for the update.

 

[cpragman]

I haven't received an email from Ars. Will you be emailing all users to let them know? A banner on the front page will only notify people that are actually loading the site today.

 

[potato44819]

The smartest password safety move I ever made as a consumer was to rotate all my passwords to being unique thanks to dashlane. Keepass and lastpass are also good options for this.

 

[pqr]

dangoodin[/url]":2e85zji4]

pqr[/url]":2e85zji4]

Bengie25[/url]":2e85zji4]

Pluvia Arenae[/url]":2e85zji4]

pqr[/url]":2e85zji4]

Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.)

He didn't assume the salt is unknown. What makes you think that he did?

Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

It all depends on what you call effective speed. In his terminology lack of salt means you can guess at all accounts simultaneously. Relative to that salt is 1/Naccount penalty (not counting you also lose rainbow tables). I only care for targeted attacks in which case salt does not slow down my adversary.

Salt prevents attackers from cracking hashes in bulk. Instead, each hash must be cracked one at a time. Stated another way, if the attacker cares only about obtaining pqr's password, salting doesn't slow things down at all. But if the attackers are interested in obtaining all or most of a breached site's users -- as I submit most attackers are -- salting drastically slows things down. This is what Jeremi meant. Hence there is no 'salt' mistake."

And there never was Only some misunderstanding. Our effective hashing rate definitions were off, reflecting those two quite different goals. It just took a while to realize that the rate definitions were different and not the assumptions about the problem.

 

[SonicMoleChaser]

Obligatory Spaceballs post.
http://youtu.be/a6iW-8xPw3k

 

[epixoip]

Addressing a few more comments here,

Powerlord[/url]":2gatdqci]
To put this into perspective, Linux distros were using 1000 iterations of salted MD5 15 or so years ago. And had switched away from it 10+ years ago.

The use of MD5 is not why md5crypt was deprecated. It was deprecated because it used a fixed iteration count of 1000 rounds, and did not employ a variable number of rounds as say PHPass does. The move from MD5 to SHA2 was done for NIST "compliance," for a lack of a better word. Same reason why MD5 was changed to SHA512 in Drupal's implementation of PHPass. SHA512 was chosen over SHA256 as the default for its performance on 64-bit systems. Also, this change was only made in late 2008, which was only 6 years ago, and it still took a couple years to find its way into the distributions (SLES being the only exception, which used Openwall's bcrypt patch.) And FreeBSD didn't make the switch until 9.1 (December 2012.)

Threz_[/url]":2gatdqci]Considering the article I quoted was talking about a single user putting a rig together to reach 350 billion hash/sec rates... an additional couple thousand hashes isn't really all that much longer. These passwords leaked from Ars will be cracked pretty quickly.

As the owner of said rig (which is now 6x faster than that, by the way), I'd like to say that no, the Ars passwords likely won't be cracked quickly. PHPass is not NTLM. As I said, on the Forbes dump (PHPass with 1M+ salts) we can only pull about 280 H/s on our cluster.

pqr[/url]":2gatdqci]Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.

I'm not assuming an unknown salt -- those numbers are with a known salt. With salted algorithms you incur a factor of N slowdown for each unique salt, as each plaintext candidate has to be re-hashed with each unique salt. So 3 MH/s with 1M unique salts == 3 H/s effective rate.

Edit: s/occur/incur/

 

[Tex Arcana]

epixoip[/url]":6jzrrnf9]Hi everyone. This is noted password cracking expert and D-list Internet celebrity Jeremi Gosney. You might remember me from here, here, here, here, here, here, or even here or here.

I would like to take a minute to address some of the comments being made about the password hashing algorithm that is used by the forum software Ars is using. Let's have a look at some of those comments.

pk![/url]":6jzrrnf9]MD5, really? After having printed several articles on password cracking I'd have hoped you'd at least have leveraged a stronger hashing algorithm.

Abhi Beckert[/url]":6jzrrnf9]
2,048 iterations is not enough to prevent a brute force attack on MD5.

d0x[/url]":6jzrrnf9]
Seriously? Ars themselves have posted many articles about this very method of encrypted password storage to be easily breakable either via brute force or with rainbow tables.

Threz_[/url]":6jzrrnf9]One the one hand, Ars calls the use of MD5 hashes for storing passwords as "unfortunate and irresponsible", and on the other (above) uses it as a way to argue that the passwords were well-"encrypted." Which is it?

FF22[/url]":6jzrrnf9]
No wonder your server was hacked if you really thought running MD5 multiple thousand times over the password would harden the hashes by any means. If anything, it weakened them.

Wow. Powerful stuff there. Too bad these armchair experts are all dead wrong.

First, when we talk about MD5 being a poor and irresponsible choice for password hashing, we're talking about raw MD5. As in a single, unsalted iteration of MD5. As in md5($pass). And as the keen Ars reader will note, the reason this is a bad choice has nothing to do with any cryptographic weakness in the MD5 algorithm itself. It's simply because MD5 is very fast and very amenable to acceleration.

One of the ways we make an algorithm resistant to acceleration is to salt it and iterate it. And no, iterating a hash does not weaken it, that's utter horseshit. Iterating a hash is what almost all password hashing algorithms do, including all crypt(3) algorithms, PBKDF2, and even bcrypt.

Ars uses phpBB, which uses the Openwall PHPass password hashing algorithm, designed by none other than the venerable Solar Designer himself. PHPass uses salted and iterated MD5 to hash passwords. It is similar to md5crypt with some key differences, and even similar to PBKDF2 to some extent. And while it may not be the best choice for password hashing, it is a solid one.

To see just how solid PHPass is, let's look back at another famous breach which used PHPass: Forbes. Back in February, Forbes had 1,071,961 password hashes dumped by SEA. Out of those 1,071,961 password hashes, 1,071,734 were hashed using PHPass.

Now as the keen Ars reader will recall, normally us professional password crackers can get a public dump 85-95% cracked within a rather short period of time. And indeed, the 227 passwords that weren't hashed with PHPass were 100% cracked in just a few short minutes. But after 10 months, we currently only have the Forbes PHPass hashes 16.19% cracked. Yes, you read that correctly. We've only managed to crack 173,548 -- or 16.19% -- of the Forbes passwords, and most of those were Top 20K passwords.

If you want to put this into "OL Hashcat" terms, a single R9 290X can pull ~ 12.2 GH/s on raw MD5, but only 3 MH/s against PHPass. Divide that by 1,071,734 unique salts, and that means our effective speed is only 2.86 H/s. That's beyond properly slow. Multiply that by 100 GPUs and that's still only 286 H/s. We can't do very much with that, and that's why this list is only 16.19% cracked.

So obviously PHPass is pretty good at what it does, and Ars has done absolutely nothing wrong by using this algorithm. It is perfectly suitable for what this site is. I've said before that password hashing is like an insurance policy, and Ars has bought you ample time to change your passwords.

And that's the way it is.

"armchair experts": owned. :lol:

 

[bluloo]

Awesome write up.

Password changed.

 

[epixoip]

Bengie25[/url]":32eidf13]
Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

There was no mistake made, and you obviously don't understand how salting works. It does indeed add a reasonable amount of extra work. You incur a factor of N slowdown for each unique salt. 1M unique salts == 1M times slower.

 

[EaseOfUseFan]

LordPixie[/url]":2mtvig48]

pk![/url]":2mtvig48]MD5, really? After having printed several articles on password cracking I'd have hoped you'd at least have leveraged a stronger hashing algorithm.

Yup, this. Ars has been quick to point out the password storage foibles of other websites. It really should have been using something better. At least it's using thousands of rounds, but still.

That being said, +1 on Ars for the notification, and for telling us to change our passwords entirely.

The salts are as much protection as the thousands of rounds, since salts essentially make hackers tasks orders of magnitude harder.

 

[pqr]

epixoip[/url]":1ovafiny]Addressing a few more comments here,

Powerlord[/url]":1ovafiny]
To put this into perspective, Linux distros were using 1000 iterations of salted MD5 15 or so years ago. And had switched away from it 10+ years ago.

The use of MD5 is not why md5crypt was deprecated. It was deprecated because it used a fixed iteration count of 1000 rounds, and did not employ a variable number of rounds as say PHPass does. The move from MD5 to SHA2 was done for NIST "compliance," for a lack of a better word. Same reason why MD5 was changed to SHA512 in Drupal's implementation of PHPass. SHA512 was chosen over SHA256 as the default for its performance on 64-bit systems. Also, this change was only made in late 2008, which was only 6 years ago, and it still took a couple years to find its way into the distributions (SLES being the only exception, which used Openwall's bcrypt patch.) And FreeBSD didn't make the switch until 9.1 (December 2012.)

Threz_[/url]":1ovafiny]Considering the article I quoted was talking about a single user putting a rig together to reach 350 billion hash/sec rates... an additional couple thousand hashes isn't really all that much longer. These passwords leaked from Ars will be cracked pretty quickly.

As the owner of said rig (which is now 6x faster than that, by the way), I'd like to say that no, the Ars passwords likely won't be cracked quickly. PHPass is not NTLM. As I said, on the Forbes dump (PHPass with 1M+ salts) we can only pull about 280 H/s on our cluster.

pqr[/url]":1ovafiny]Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.

I'm not assuming an unknown salt -- those numbers are with a known salt. With salted algorithms you occur a factor of N slowdown for each unique salt, as each plaintext candidate has to be re-hashed with each unique salt. So 3 MH/s with 1M unique salts == 3 H/s effective rate.

Figured out how this detour could have been avoided. Units of that rate should be 3 hashes/sec/account Whereas I thought you were solving different problem (unknown salt-assignment) which means 3 hashes/sec/salt for given account.

 

[epixoip]

Gern Blaanston[/url]":7c4tdeqi]So far, all the discussion has revolved around the good/bad points of MD5. And while it's all quite interesting, I find the first sentence of the article more troubling:

"an Internet intruder gained access to one of the Ars Web servers"

These intrusions seem to be becoming more common and there really seems to be a systemic problem of people not taking security seriously (despite paying lots of lip service). Don't get me wrong, strong encryption on your database of user passwords is a very good thing. But not letting people get to that database in the first place is, in my opinion, even more important.

Not much you can do about 0days. Webapp has to talk to the database, if you compromise the webapp then you also have access to the database. This is why we employ strong hashing -- it's an insurance policy in the event of a breach.

 

[Ligushka]

bthylafh[/url]":aqq3wmao]Just out of curiosity, what's Ars' max password length?

Seems like 100. I tried 200 out of paranoia and curiosity and it said it was too long. I was able to use brackets and high-ANSI characters this time around, though, and I can still log in!

 

[Theala Sildorian]

vampireaquid[/url]":3qrdknwb]Thanks for the headsup. Times like this make me happy I bought 1Password.

This is the second time in a year I've had to do this . . . but that's not a criticism of Ars. This happens too often; this just reinforces that I need to use more passwords and a master to keep it manageable.

 

[Control Group]

Hinton[/url]":373ota83]

Control Group[/url]":373ota83]Just wanted to say thanks for handling this the way organizations should handle it. Rapid response first, public acknowledgement as quickly as practicable, along with a clear explanation of what got hacked, what's at risk, and what the users' best course of action is.

Ars is a website specifically dealing with the subject, not a random business.

Get over yourself.

Something stairs something the queen something something.

In other words, who shat in your Cheerios? Doing the right thing doesn't become less virtuous just because you're someone who knows what the right thing is.

 

[epixoip]

pqr[/url]":3neybash]
Figured out how this detour could have been avoided. Units of that rate should be 3 hashes/sec/account Whereas I thought you were solving different problem (unknown salt-assignment) which means 3 hashes/sec/salt for given account.

No, I'm afraid you're still not getting it. I was most certainly not solving the problem of unknown salt assignment. Again, my calculations were with a known salt for each hash.

The overall effective speed of the entire attack would be 3 H/s. As in, if you were to load this list up in oclHashcat and start cracking it, oclHashcat would report the speed as 3 H/s. As in, you can only try three candidate passwords per second against all hashes. Except it would be even slower than that on a 290X because AMD has a shitty memory controller and you incur a penalty for loading a hash list of that size. Here, let me show you. Actual attack with a 290X against the Forbes PHPass hashes.

Session.Name...: oclHashcat
Status.........: Aborted
Input.Mode.....: File (/home/epixoip/rockyou-sorted.txt)
Hash.Target....: File (/home/epixoip/forbes-php.hash)
Hash.Type......: phpass, MD5(Wordpress), MD5(phpBB3), MD5(Joomla)
Time.Started...: Tue Dec 16 16:50:26 2014 (15 secs)
Time.Estimated.: Wed Aug 5 00:59:31 2015 (231 days, 7 hours)
Speed.GPU.#1...: 1 H/s
Recovered......: 3/1071734 (0.00%) Digests, 3/1071734 (0.00%) Salts
Progress.......: 11714560/15347819261966 (0.00%)
Skipped........: 180224/11714560 (1.54%)
Rejected.......: 0/11714560 (0.00%)
HWMon.GPU.#1...: 0% Util, 54c Temp, 100% Fan

So in reality, only 1 H/s effective rate. Thanks AMD.

Again, the reason for this is because each plaintext candidate has to be re-hashed with each unique salt. This is where your factor of N slowdown comes from. So if you have 1M salts, you have to hash one candidate 1M times in order to compare it to the hash list.

Edited to add oclHashcat output

 

[Deleted member 192806]

Theala Sildorian[/url]":upat170f]

vampireaquid[/url]":upat170f]Thanks for the headsup. Times like this make me happy I bought 1Password.

This is the second time in a year I've had to do this . . . but that's not a criticism of Ars. This happens too often; this just reinforces that I need to use more passwords and a master to keep it manageable.

If this (in general) is going to be a regular occurrence, maybe someone can automate the whole process?

 

[pqr]

epixoip[/url]":1g3dv8z4]

pqr[/url]":1g3dv8z4]
Figured out how this detour could have been avoided. Units of that rate should be 3 hashes/sec/account Whereas I thought you were solving different problem (unknown salt-assignment) which means 3 hashes/sec/salt for given account.

No, I'm afraid you're still not getting it. I was most certainly not solving the problem of unknown salt assignment. Again, my calculations were with a known salt for each hash.

The overall effective speed of the entire attack would be 3 H/s. As in, if you were to load this list up in oclHashcat and start cracking it, oclHashcat would report the speed as 3 H/s. As in, you can only try three candidate passwords per second against all hashes.

Again, the reason for this is because each plaintext candidate has to be re-hashed with each unique salt. This is where your factor of N slowdown comes from. So if you have 1M salts, you have to hash one candidate 1M times in order to compare it to the hash list.

Funny that both Dan and you feel the need to keep restating the obvious in your last posts. Be it. I explained clearly what I thought you were originally doing. It should also be evident that I have been using past tense in the last couple posts, i.e., I know that you had something else in mind. I have no further thing to say as both definitions are clear*, they are different, and meaningful in different contexts. So be not afraid, I am very much getting it (perhaps you are not getting this last statement, or not wanting to, but that I leave to you to deal with).

*EDIT: heck, even conversion between the two is trivial

 

[epixoip]

pqr[/url]":mkwl97hn]So be not afraid, I am very much getting it (perhaps you are not getting this last statement, or not wanting to, but that I leave to you to deal with).

You said the units should have been expressed as "3 hashes/sec/account", and that is wrong. That is what leads me to believe you are still not getting it. The units per account would be 3 MH/s/account.

 

[pqr]

epixoip[/url]":2yeoi4nu]

pqr[/url]":2yeoi4nu]So be not afraid, I am very much getting it (perhaps you are not getting this last statement, or not wanting to, but that I leave to you to deal with).

You said the units should have been expressed as "3 hashes/sec/account", and that is wrong. That is what leads me to believe you are still not getting it. The units per account would be 3 MH/s/account.

Sure. Let me quote what I wrote:

Whereas I thought you were solving different problem (unknown salt-assignment) which means 3 hashes/sec/salt for given account.

Again, I did not state this is the problem you solved. But sure this was the problem I originally thought you solved. There is no contradiction here.

The sentence prior to that one even tells that had the result been written as 3 hashes/sec/account these couple hundred words back and forth would have all been avoided but that is OK, bits are cheap, and I learned what you guys mean by effective rate.

 

[Hinton]

Control Group[/url]":2po07cqr]

Hinton[/url]":2po07cqr]

Control Group[/url]":2po07cqr]Just wanted to say thanks for handling this the way organizations should handle it. Rapid response first, public acknowledgement as quickly as practicable, along with a clear explanation of what got hacked, what's at risk, and what the users' best course of action is.

Ars is a website specifically dealing with the subject, not a random business.

Get over yourself.

Something stairs something the queen something something.

In other words, who shat in your Cheerios? Doing the right thing doesn't become less virtuous just because you're someone who knows what the right thing is.

Them not doing so would have been very interesting.

But no I am not exactly overflowing with grateful emotion for them doing what they've been preaching that everyone else should do for years.

I mean, my response would be more along the lines of "OK, noted.".

 

[True_North]

Damn! with all this discussion of hashing,MD5,etc ad nauseam,
I feel like the scarecrow from Oz.

 

[zladuric]

Regarding the defacement: where's the screenshot?

Pic or it didn't happen

 

[jasonmicron]

Well luckily I don't use this password anywhere else. I suppose I will change it but yea, if I dont, what is the worst that would happen? Someone trolls and my account gets suspended or something? I'd just make another account.

...nah, I'll just change the damn thing. Thanks Ars.

And +1 to those comments about banking and finance websites with limited password restrictions. KeePass is so awesome that I've routinely broken their rules. My favorite is an old employer I had. For identity management admin access the password rules were asinine like:
1) no password longer than 8 characters
2) only one number
3) must have at least 2 symbols of these:! $#&?, - that's it

This was for a major oil and gas company as of 9 months ago.

 

[gmerrick]

Ladnil[/url]":20tm5f39]

systemsready[/url]":20tm5f39]Erm....what if you don't remember your password...?

Ask the hacker, maybe he can remind you!

Call the NSA lost password hotline! Right here under Information Assurance

https://www.nsa.gov/ia/contacts/index.shtml

 

[pqr]

zladuric[/url]":jzsyz162]Regarding the defacement: where's the screenshot?

Pic or it didn't happen

Try middle near bottom of comment page 3.

 

[Jedakiah]

epixoip[/url]":v05p7k99]

Bengie25[/url]":v05p7k99]
Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

There was no mistake made, and you obviously don't understand how salting works. It does indeed add a reasonable amount of extra work. You incur a factor of N slowdown for each unique salt. 1M unique salts == 1M times slower.

Evidently I don't understand how it works either, which is quite embarrassing. I was under the impression that a salt is a random string added to the end of the password before it is run through a hashing algorithm. So you generate a random string like "Ar2cjWo3rc", append it to the end of your password "hunter2Ar2cjWo3rc", then you store the hash and the salt in your database. Of course typically your hashing algorithm stores the salt and hash together in the same output string saving you a column in the database.

Where does the 1 million figure come in? The only way I can picture a hacker having to run a million attempts on each hash * your iterations is if you are using a precomputed list of a million hashes stored elsewhere, and randomly select one each time a user registers. The you store no info about which one you selected. If so then Ars too has run a million attempts on each hash every time a user tries to log in. That whole system seems odd, mostly because I have never seen it implemented before. Why store precomputed hashes instead of just bumping the iterations? It would add complexity and tax the database. I am assuming I am way off here, hence my question about how this works.

 

[El Chupageek]

huxley[/url]":2etay78h]

El Chupageek[/url]":2etay78h]

foobacca[/url]":2etay78h]

bthylafh[/url]":2etay78h]

JGJones[/url]":2etay78h]Folks using randomly generated passwords via password managers - why limit yourself to 32 characters?

Because lots of websites have a limit on how long your password can be. My natural gas utility, for instance, limits me to 10 alphanumeric characters. Unless they've changed it recently, Microsoft limits us to 16 characters.

If passwords were limitless, you'd have some asshole uploading hello.jpg or a copy of War and Peace as his password.

And when you use a good password hashing algorithm, very long passwords can be used to cause a Denial of Service attack - such as this one fixed in Django (and ars coverage ). Django was fixed by making it refuse to accept passwords longer than 4096 bytes - which is more than long enough for me.

That really should be "Fixed" - the problem still exists, it simply takes more requests to exploit. Not an impractical number more mind you - you need to increase your requests by a factor of a couple hundred, but that's still super cheap. If they have proper flood control in place they can probably prevent those attacks by detecting the increased request rate and blocking, but very few companies do this well.

The problem with expensive password hashing is that it creates an inherent asymmetry between the cost to make a request and the cost to process it, which is a scenario that enables easy DoS. Posting a username/password takes an incredibly small amount of bandwidth, CPU, and memory for the attacker, but an exponentially larger amount of CPU and memory for the processor. Its just an inherently flawed idea, and the Django modification doesn't fix it, it simply makes the attack something slightly less than trivial

The 4096 character limit was a temporary fix that only existed for Django 1.4.8/1.5.4, the password hashing algorithm was improved in Django 1.4.9/1.5.5 to avoid both the limit and the denial-of-service via password hasher (all that took place between September and October 2013, we're now on Django 1.7.1)

Thanks for the update - that's great to hear

 

[talon_262]

Modern Major General Thanatos[/url]":22aeld3t]The smartest password safety move I ever made as a consumer was to rotate all my passwords to being unique thanks to dashlane. Keepass and lastpass are also good options for this.

For keeping track of all of my passwords and making it dead simple to change any of them quickly and easily, no matter what device I’m on, LastPass Premium is the best $12/year that I spend.

 

[Andara]

bthylafh[/url]":3j98j4ne]

JGJones[/url]":3j98j4ne]Folks using randomly generated passwords via password managers - why limit yourself to 32 characters?

Because lots of websites have a limit on how long your password can be. My natural gas utility, for instance, limits me to 10 alphanumeric characters. Unless they've changed it recently, Microsoft limits us to 16 characters.

If passwords were limitless, you'd have some asshole uploading hello.jpg or a copy of War and Peace as his password.

And for extra fun, some sites limit length, but don't inform you that they do, so you enter Thi$iSmyPas$w0rd and it only gets Thi$iSmyPa and truncates the rest at account creation, but rejects anything longer than 10 characters when logging in, so even though you're using the same exact string, it fails.

JGJones[/url]":3j98j4ne]Us password managers users can remain smug in the fact that we use unique passwords for every site and pity those poor saps that don't...That's the real power of a password manager.

I don't use a manager and still manage to have unique passwords for every site.

And I'm not hosed if I lose access to my manager.

choctawfootball[/url]":3j98j4ne]I don't believe that password is as secure as you think it is.
You need symbols (!@#$%^&*), to make it truly secure.

There comes a point where greater length adds more entropy than expanded character sets. I'm fairly certain that 20 characters is still past that point.