I work in one of these offices. It's most likely glue fumes, but the booths definitely have a very strong smell and have given some of my colleagues headaches when used for any length of time. The booths have been there for a few months now and had been left open to air out, and the smell is as strong as ever. Airing them out alone hasn't worked, but it's also not the end of the world here - we just aren't using the booths until they're replaced.

The salt's 100% server side - the client never knows about it, or even if his/her password is being salted and hashed, or stored in plaintext (unless they're able to send you your password - then you know it's stored in plaintext).

It depends how they're trying to break into the system, but typically no. If they're trying to send lots of login attempts against the the established authentication system, that's something you as a server admin can detect. To protect against it, you can rate limit requests from that ip address. For example: the first 3 password attempts within n-seconds execute as fast as your servers can handle, but on every subsequent attempt you delay the response by a quarter second, then a half second, then a full second, then two seconds, etc. If they try too often, you can ban the ip address**, and possibly have the server send out a message to the admins.

If you were to have the client send up the salt with their password (or hash it themselves), you'd be correct. But the server's the one who generates and stores the password, and the client never sees it or knows about it.

True, but you can detect when something is sending thousands or more password attempts at a server and block it.

Exactly; almost all these comments assume the attackers have gained access to your database. The idea is that even if they can get your data directly, they still won't be able to figure out a user's login credentials. Depending on what your site does, that may or may not be a big deal for your users. As a user, if they got a copy of my profile on linkedin, I wouldn't care too much. It'd be bad, sure, but not the end of the world. If they could figure out my password and log in to the site, and start posting as me, that's a problem. Same thing with banking credentials (knowing my balance vs. being able to change my balance), and most places where I need a password.

The other problem is password reuse. Many users reuse their passwords on multiple sites. That means if you can crack a million user's linkedin accounts, you now have their email + passwords. If you then try logging into gmail with those same emails + passwords, you might get in to 100,000 of them. And then you can try their other accounts (say, banking) and even if those fail, you can try to do a password reset, and if you own their email address you can usually "confirm" the reset and set their password to whatever you want.

I learned a lot of this first at college, then over time as I've seen how people implement their systems. Wikipedia has some info on salting, but mostly it's rehashing what I've said (http://en.wikipedia.org/wiki/Salt_(cryptography)). Doing a quick google search, this page seems to do a very good job at explaining this stuff: http://crackstation.net/hashing-security.htm. Just remember this all assumes they have access to your database. The only extra thing I'd add to what they describe is to also include an application password secret that's stored in your config files (or some other place outside your database). That way if they only have your database but not your config files, they won't be able to break any passwords. To do that just do $applicationPwSecret+$salt+$password instead of $salt+$password. Order doesn't matter, as long as your consistent across every password (i.e. $salt+$password vs. $password+$salt)

**Do take care when banning an ip though - there are lots of legitimate reasons users can share ip addresses. Some ISPs put their users behind NATs, as might schools and some countries.

You have a good point regarding using botnets to break the salted passwords, since as you say it's highly parallelizable. At the same time, why make it easy for them? If they have to rent time on a botnet to break the passwords (or spin up a bunch of gpu instances in ec2), so much the better. Especially if you use a slow hash algorithm - if it takes .01 second per hash attempt, and you have a million users with unique salts, they'd have to spend 0.01 * 1,000,000 seconds per password attempt per user, which is 10,000 seconds, or cpu 2.7 hours. That means to test the letter "a" on every user, they'd spend 2.7 cpu hours. Even with a massive botnet I imagine that would get prohibitively expensive really quick. If they had 10 million machines in a botnet, it would take 10,000/1,000,000 = 0.01 real seconds per password attempt per user. A standard dictionary might have something like 40 million entries (http://www.openwall.com/wordlists/). That translates to 400,000 seconds to try the entire dictionary, or 111 real hours**. Doable, but hopefully expensive (I'm not sure the going hourly rate of a 10 million machine botnet). Feel free to check my math, by the way.

**Of course users usually pick bad passwords, and the common ones could be checked first, so it's unlikely they'd have to run the entire dictionary to crack most of the passwords.

There are different methods to come up with the salt. I typically use a "random" byte array (32 bytes or something). I'm not exactly sure the bcrypt algorithm's salt generator. Some people use the user's id (though that's not very useful if it's just a Long. Could work if it's a guid). It doesn't really have to be random so much as unique, and enough bytes that it's long enough make a rainbow table useless (i.e. if you use 2 bytes of salt, and a user has a 6 character long password, a rainbow table that has all passwords that are 8 bytes long will still contain the password+salt combination).

You store the salt in plain view in the database, along with the user's password. You can even store the salt in same field as the hashed password like so: $hash$salt (you can extract the hash because it's a known length, same with the salt, or you can use an actual separator between the two). The salt isn't intended to be secret. It's purpose is to thwart someone who has a big table of hashes -> passwords, guaranteeing your passwords won't be in that list. Likewise, if two people have the same password, they'll have different salts, so their hashes will be different. This means if they figure out one hash -> password, it won't tell them anything about any other passwords.

Salting still helps because it makes rainbow tables useless - you'd have to generate a rainbow table for each salt. Since the salt is used only once (unique per user), you'd have to brute force each password individually.

You are correct that md5 hashes can be generated very, very quickly now, so millions of password combinations can be tried per second, but it effectively multiplies the amount of work an attacker would have to do by the number of users (assuming they try to break every password). Using something like bcrypt (http://en.wikipedia.org/wiki/Bcrypt) which incorporates salt + a hashing algorithm that takes longer to calculate can make cracking passwords *much* more difficult as each password attempt takes more than 0.00000001 seconds, and they have to do it for every user.

Then for bonus points, if you then ALSO use a (long) global salt that you don't store in your db (i.e. in a config file), they won't be able to crack any passwords unless they can also get access to your config files.

From what I understand, neurons die and are replaced all the time. I think they last longer than most cells, but at least some of them do die and are replaced. I could be wrong about this as I haven't studied it, but lets assume it's true.

If this is true, then your brain is slowly being replaced. The "you" that you are now isn't the exact same "you" as was you N years ago.

What if you use technology to slowly replace dying brain cells with new "immortal" brain cells? There is no "copy" - there is always only one of "you" - but eventually your consciousness will be immortalized.

By making this a gradual thing rather than an instant thing does that make it any more appealing? In the end, you end up in the same place (original brain gone, electronic brain working) but there's a single stream of consciousness from A to B rather than potentially having two copies of you where one of them dies. From what I understand, this happens as time goes on anyway so would "you" notice a difference?

This is one of the scariest arguments I've ever seen. You're saying we should avoid a topic because some crazies have taken a liking to it. An analogous argument is that because there are faith healers, homeopathic "cures," and the like, we shouldn't study medicine. Not only should we not study medicine, but any educated person would clearly avoid the discussion of medicine. Lucid dreaming exists. There's nothing mystical about it. The fact that there are crazies and disreputable individuals trying to make a profit off it doesn't diminish that fact.

Yup, that's exactly how it works. If you look at the url the ad links to you'll notice it's a link to google.com with a bunch of meta data, which then redirects to the site you clicked on. The meta data logs a variety of things (the terms you searched for, the location of the ad on the page, the site to redirect you to, etc.).

It's worth noting that many of the statistics gathered are available to the advertiser through Google's analytics package, letting the advertiser know which campaigns are more or less successful at getting clicks, and which have better conversion rates. Not that I'd expect many advertisers to complain that you went to their site directly instead of through the ad...