Live data from Hacker News

The FBI stole an Instapaper server in an unrelated raid

blog.instapaper.com

81–90 of 263 posts

Re: The FBI stole an Instapaper server in an unrelated raid

#81
post #67
post #36

Earlier quoted context omitted.

> can brute force millions Modern consumer video cards can do billions per second now. You might as well just store them in plaintext instead of using SHA1/MD5 with or without salting. :/

I dont understand. If you can use mixed-cased, letters and symbols you have 26 * 2 + 20 = 72 possible characters. 72^8 >> 1e9 It would still take more than 8 days to brute force at 1 billion/sec. And using a longer password (16 chars?) would make this a very long time. Or is there other trick that makes this fast? Or, is it simply that people don't choose random, long passwords?

You're looking at more like 5+ billion/sec today. There was a listing of modern consumer video cards + their hashing capabilities posted on another HN story recently, but I can't find it.

Re: The FBI stole an Instapaper server in an unrelated raid

#82
post #25

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. -- Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "safe". Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU. If the FBI so wanted (although I don't believe they do) I'm sure they could brute force almost every single password in that database. Granted,…

So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?

Re: The FBI stole an Instapaper server in an unrelated raid

#83
post #73

Earlier quoted context omitted.

There is virtually no chance that, after selecting bcrypt, you will be forced to scramble to replace it in 2 months. There is no chance that, after selecting bcrypt, you will be forced to scramble to replace it with salted SHA-1 hashes. bcrypt is strictly better than what you're doing now.

Fantastic. One more question: does increasing the work factor automagically upgrade existing passwords in some way? As in, will bcrypt passwords created today be strong enough in 2020?

No; you'd upgrade them incrementally.

Re: The FBI stole an Instapaper server in an unrelated raid

#84
post #41

Earlier quoted context omitted.

I have been thinking about switching everything to bcrypt, but there is definitely way too much confusion about bcrypt vs scrypt, how many rounds to set for bcrypt, etc. What is the definitive source for figuring out what the new standard should be? Does anyone have any links to something that's peer-reviewed and approved for use by someone with enough authority to do so?

No there isn't. You only think that because when geeks discuss anything that involves one or more knobs, a huge debate must necessarily ensue about the proper values of those knobs. Just use the bcrypt defaults. You will be fine. You will in particular be so much better off than salted SHA-1 that this topic will be mooted. Later on, maybe in 5-10 years, you can re-engage with the debate about what a good cost factor…

In the defense of geeks, this probably follows from the mantra that you should never ever run any command on your system ever without completely and fully understanding what it does and all of its options and etc. etc.

So now people are twitchy about "just use the defaults", especially when it comes to something they don't really understand, like cryptography.

Re: The FBI stole an Instapaper server in an unrelated raid

#85
post #73

Earlier quoted context omitted.

There is virtually no chance that, after selecting bcrypt, you will be forced to scramble to replace it in 2 months. There is no chance that, after selecting bcrypt, you will be forced to scramble to replace it with salted SHA-1 hashes. bcrypt is strictly better than what you're doing now.

Fantastic. One more question: does increasing the work factor automagically upgrade existing passwords in some way? As in, will bcrypt passwords created today be strong enough in 2020?

The Ruby on Rails auth system I use, Devise [1], will automatically update a user's password to use your new work factor on their next login.

You could do something similar.

[1] https://github.com/plataformatec/devise

Re: The FBI stole an Instapaper server in an unrelated raid

#86
post #25

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. -- Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "safe". Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU. If the FBI so wanted (although I don't believe they do) I'm sure they could brute force almost every single password in that database. Granted,…

So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?

Convert as sessions expire and people sign in again. You'll obviously need a db column to keep track of which passwords are converted/unconverted, e.g. password_algo.

Re: The FBI stole an Instapaper server in an unrelated raid

#87
post #33

Surely there is a legal precedent which provides at least some framework for what can or cannot be seized during a warrant search? This can't be the first time government agents have mistakenly seized property in an otherwise lawful search. Also, while I completely understand Instapaper's unwillingness to pursue this through the courts, that is the way our legal system is structured. If you believe you have been harm…

It's called the constitution of the United States. If the enforcers don't follow it, your only recourse is the Supreme Court which will probably throw out your claim for national security reasons.

Not necessarily. I (also) am not a lawyer, but the question isn't whether the FBI has the authority, constitutional or otherwise, to seize the servers owned by the target of the warrant, the question is whether they overstepped their bounds in seizing three whole racks of servers. If it's shown they were careless or did not take sufficient caution in their raid to avoid seizing unrelated servers, they could be held liable for damages. In this case in particular, the number of unrelated companies that have been affected by this (and the number of servers present in 3 racks) makes a case for negligence.

Again, though, the question isn't whether they had the right to seize the servers they had warrants for - they did, and you won't get that questioned by any court - but whether they did so properly, and it's not unheard of for a law enforcement agency to get slapped for overstepping their bounds. It's not Common, but it's not unheard of, and it's not a 4th amendment issue either.

Re: The FBI stole an Instapaper server in an unrelated raid

#88
post #25

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. -- Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "safe". Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU. If the FBI so wanted (although I don't believe they do) I'm sure they could brute force almost every single password in that database. Granted,…

So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?

You can bcrypt your current sha1 hashes.

Re: The FBI stole an Instapaper server in an unrelated raid

#89
post #25

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. -- Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "safe". Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU. If the FBI so wanted (although I don't believe they do) I'm sure they could brute force almost every single password in that database. Granted,…

So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?

I've had the "joy" of doing password migrations in the past when moving authentication systems. We made our auth chain support both methods and then when someone logged in with an old method it stored the password in the new method and deleted the old record. This was on a system with only a few hundred users though, so YMMV.

Re: The FBI stole an Instapaper server in an unrelated raid

#90

I think it may be prudent to begin encrypting all data on disk that can reasonably be encrypted while being able to set up the server remotely so that no one can just snatch your server and get all your data. This could work by encrypting your database in a truecrypt volume that must be mounted by entering the password. Thus, the data is only ever saved on disk in encrypted form, and the key to access the data is not…

How fast is Truecrypt? How much would this slow down database and file access?

Truecrypt is significantly slower, especially on the higher strength encryption methods. The program itself has a benchmark in it, so download it and check it out for yourself if you're that curious. (Note that it is relative to your hard drive's speed)
Post reply on HN