All the more reason for data havens to exist. Run your server from a country where the police can't just take it with impunity.
The CIA doesn't even need warrants .
In the US? The CIA can't operate in the US.
The FBI stole an Instapaper server in an unrelated raid
161–170 of 263 posts
Re: The FBI stole an Instapaper server in an unrelated raid
#162Re: The FBI stole an Instapaper server in an unrelated raid
#163Instapaper 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,…
Just store in plaintext because I am already assuming you are. All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. I believe that most people are using the default password storage mechanism for their framework which are already known to be easy to break if the database is compromised. But all of that is mute anyways. Unless you have access to the site's source how would you know if they are hashing at all much less which one they are using? The best practice is to use a random password for each site you use. I just don't see any point in having an rememberable password for websites and hashing just leaves a false sense of security as illustrated by md5.
Re: The FBI stole an Instapaper server in an unrelated raid
#164Earlier quoted context omitted.
Do you have any suggestions on safe countries? As far as I can tell, the USA is still has the best mixture of freedom and protection available.
The Netherlands, Sweden, etc. provide pretty good coverage and is where a lot of the seedboxes for torrenting are held. If you have something you want the government to have a almost nonexistent (depending on what it is) chance of getting to, go with Russia, China, etc. and other countries that probably don't have the best relations with the United States.
Russia and China are perhaps good examples of places to host something the US government has little chance of getting to, but the governments of those countries are far worse about this sort of thing than that of the States, so I wouldn't want my data to be stored there.
Re: The FBI stole an Instapaper server in an unrelated raid
#165Earlier quoted context omitted.
What's a ready to go bcrypt library for C/C++? I mean include headers, link lib / so, and call a function. I've been looking into this over the past few days, and I've decided to just extract the relevant files from py-bcrypt, and get rid of the compatibility layer.
The C reference implementation is here: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/ Its from OpenBSD and implemented by the developers of the algorithm. It is what the Python/Ruby/Lisp/PHP etc. versions are derived from or wrap
Thanks!
Re: The FBI stole an Instapaper server in an unrelated raid
#166Instapaper 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,…
Just store in plaintext because I am already assuming you are. All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. I believe that most people are using the default password storage mechanism for their framework which are already known to be easy to break if the database is compromised. But all of that is mute anyways. Unless…
... what?
> Just store in plaintext because I am already assuming you are.
No, actually, I don't think I will store plaintext passwords.
> All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does.
So what? Just because other people don't do it doesn't mean you don't have to also. Fortunately for us, there are a lot of startup founders here who might read this and learn something.
> I believe that most people are using the default password storage mechanism for their framework which are already known to be easy to break if the database is compromised.
I disagree. I think most people use SHA-1 because they know better than to store plaintext passwords. What they don't know is that it's terribly broken.
> But all of that is mute anyways.
No, it's really not.
> Unless you have access to the site's source how would you know if they are hashing at all much less which one they are using?
There are two problems here. (1) If you have access to the site's password database, there's a really good chance you have access to the entire database, and can look up how they're doing it. (2) Even if you can't lookup how they're doing it, you just try them all and find which one it is. I'd bet you money that if someone's hashing passwords, they're using one of {MD4, MD5, SHA0, SHA1, SHA2, DES}. If, god forbid, they're not using one of those and actually wrote their own hashing algorithm, you have even more to worry about.
> The best practice is to use a random password for each site you use.
For sure, no doubt about it. But what we're talking about here is the best practice for application developers, not the users. The users can't do anything about how their password is stored.
> I just don't see any point in having an rememberable password for websites and hashing just leaves a false sense of security as illustrated by md5.
Or, you know, you could use bcrypt and be secure about it.
Re: The FBI stole an Instapaper server in an unrelated raid
#167Earlier quoted context omitted.
That was my first thought too. Not only does the FBI have the salted hashes, but they also have a copy of the code for the website. So they know what the salt values are. This makes it even easier to brute force the hashes.
You've been downmodded because password hash salts are public nonce values; usually, schemes that depend on "secret salts" are crackpot alternatives to secure password hashes. (I didn't downmod you).
I was thinking more along the lines that knowing how the nonce(s) were added to the password would make it easier to scan for password in a brute force manner. For example, if you know the hashed password would be in the form 'nonce:username:password', it would be easier to know when you found the correct password, regardless of what the nonce is.
Re: The FBI stole an Instapaper server in an unrelated raid
#168Instapaper 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,…
Was far happier when he didn't store passwords at all, tbh.
Re: The FBI stole an Instapaper server in an unrelated raid
#169Earlier quoted context omitted.
Just store in plaintext because I am already assuming you are. All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. I believe that most people are using the default password storage mechanism for their framework which are already known to be easy to break if the database is compromised. But all of that is mute anyways. Unless…
... what? > Just store in plaintext because I am already assuming you are. No, actually, I don't think I will store plaintext passwords. > All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. So what? Just because other people don't do it doesn't mean you don't have to also. Fortunately for us, there are a lot of startup foun…
> So what? Just because other people don't do it doesn't mean you don't have to also. Fortunately for us, there are a lot of startup founders here who might read this and learn something.
Yes I hope there are.
> I disagree. I think most people use SHA-1 because they know better than to store plaintext passwords. What they don't know is that it's terribly broken.
SHA-1 is the default on django and its easy to break that my entire point. It leaves a false sense of security.
> There are two problems here. (1) If you have access to the site's password database, there's a really good chance you have access to the entire database, and can look up how they're doing it. (2) Even if you can't lookup how they're doing it, you just try them all and find which one it is. I'd bet you money that if someone's hashing passwords, they're using one of {MD4, MD5, SHA0, SHA1, SHA2, DES}. If, god forbid, they're not using one of those and actually wrote their own hashing algorithm, you have even more to worry about.
They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security.
> Or, you know, you could use bcrypt and be secure about it.
For how long? 4-5 years? Who will be maintaining your site then?
Re: The FBI stole an Instapaper server in an unrelated raid
#170I'm trying to think of an analogy which can explain why this might be reasonable from the FBIs perspective. Suppose you were using a shared storage space (shared servers, or server farm) with several other dudes. One of them is a drug dealer. One day the police/FBI decide to raid the storage space since the drug dealer has been using it to store illegal drugs. Is it not reasonable to consider this collateral damage (…
I can certainly think of scenarios in which this action was reasonable from the FBI perspective.
I don't like to be in the position of defending the FBI (my own personal and professional relationship with them is complicated), but I think the following situation is plausible (which isn't to say it's what happened, as we don't know):
FBI determines the originating IP address of whatever their investigation is targetting (based on published information, it looks like a "scareware" operation").
FBI determines the IP address is "owned" by an overseas hosting provider, and that the physical servers are in a datacenter in the U.S.
FBI obtains a warrant for the seizure of all associated computing equipment (which may very well include the upstream devices used by the hosting provider).
FBI executes warrant at datacenter, sees that the servers are actually blades in a chasis; takes entire chasis (as reconstructing the data later on may require that the servers be bootable.)
The very last forensic case I worked involved having to acquire evidence from a server which was hosting a web application by a hosting provider. This was a shared hosting scenario, so in addition to acquiring the targeted information, all other customers on the server were also effectively offline (as the server was being imaged, and later as the original hard drives were entered as evidence).
Now, obviously, that isn't the exact same situation as what is described here, but in the event that the servers were blades, I don't think it's outside the realm of possibility to think that the entire chasis would need to be retrieved.