Just like everyone working in a restaurant needs to know the basics of food handling in order to avoid getting people sick, everyone who's operating a website with logins has a responsibility to:
a) Not send passwords over http
b) Not send passwords via GET (which is typically logged)
c) Hash their passwords
Anything less, and you're putting the public in danger.
I just have a simple LAMP server and I don't really understand Apache. How do I make it "https"?
http://www.startssl.com/ will give you a free SSL cert.
They've got a "How to install" section that specifically deals with Apache (and another one which deals with WHM/cPanel if you're using that for your LAMP management).
It's less than an afternoon's work to get up to speed.
Note that you'll need a dedicated ip address (or you might settle for a server running new enough versions of Apache to use SNI - http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI - but that'll still not work for IE6 and very old versions of other browsers - pre 2.0 for Firefox)
There are basically two steps, both of which can be at no additional cost:
1. get a certificate, and
2. configure your server to use the certificate.
You can generate a certificate yourself, without paying anyone, and it will work fine, but some browsers will throw up a warning page if it is not signed by an authority (more: http://www.namecheap.com/support/knowledgebase/article.aspx/...).
You can get free certificates backed by a CA trusted by most browsers, for example at https://www.startssl.com. There are some limitations (e.g. no wildcard certificates) but it's still much better than a self-signed one.
I occasionally quickly cook meals in my kitchen. I never figured out what I should do exactly to set up the dishwasher with detergent, without needing to pay for the detergent.
I just have a simple kitchen and I don't really understand dishwashing. How should I make it "hygienic"?
(That guy would get shut down by the health authorities as soon as he started serving food to the public. Why aren't web developers offering their systems to the public held to basic data safety practices?)
and FTR, I did not grow up knowing how to use dishwashers but was quite aware of the basic relationship between the act of dishwashing and detergents. Extrapolating that fundamental relationship to a dishwasher is to say the least -- elementary.
If you'll allow me to shamelessly self-promote. We make it really easy to do this correctly using an email and password at my startup: https://www.dailycred.com/
In particular, a man-in-the-middle can capture the redirect to DailyCred and instead send the user to some trojaned site to capture their username and password (and then forward it on to you to get a legitimate token, but the password's been leaked in the process).
I don't think it's helpful to say "we do HTTPS so you don't have to". Your users still need to be using HTTPS and preferably HSTS, unless I'm misunderstanding the intended use case. (I'm very happy to see that you guys do HSTS, though!)
Because of this narrow risk, we encourage our clients to still get ssl certs as they grow. However, when they are small MVPish non-sensitive apps with 50 users, the risk of this kind of attack is very small. (For example, Facebook Connect, which has the same vulnerability I described, would be a much more obvious target with a very high payload.)
The way we see it is getting people who are about to either store plaintext passwords or not salt their hashes correctly or pass them over non-https (like HN by default, boo!) or mess up a dozen other things, we're much more secure.
1. It's a shitty UX
2. There are more people without an OAuth provider than there are with them
3. It's a sure fire way of killing your conversions
4. It means people start getting tethered to providers
5. It's very complicated when it goes wrong
6. THIS DOESN'T SOLVE THE OP'S QUESTION AT ALL. OP POINTS IT OUT. YOU IGNORE OP.
Enabling SSL stops people sniffing sensitive data on public wifis. That's why everyone says enable SSL by default.
Also there's something wrong if you're a programmer and can't afford an SSL cert as it's the same price as a couple of beers.
I also find your password advice extremely questionable, it just doesn't make sense to me.
As for making it https, (hypothetical web developer) most cheap hosting providers actually provide tools for managing certs and apache configs in cpanel. It's not too difficult to do yourself. Basically install mod_ssl and copy paste a standard config, substituting the pathnames for the paths of the certs you got from a CA.
I understand that your average beginning-throw-up-a-website-for-a-business would find this difficult, but they can hire someone for an hour to install their certificates.
Wtf guys? Didn't we /just/ do this about GoDaddy? Just say NoDaddy.
free certs: https://cert.startcom.org/ or https://www.startssl.com/
Yes, you can buy a cloud offering, but physical disk is still way cheaper than "cloud disk". You don't have all the cloud features, but on the other hand, the data are 100% yours, on a server that you control.
I've been trying to actively discourage the use of FTP for the last 10+ years. It's not an option because it passes passwords in-the-clear. Protocols that pass cleartext authentication should just be off the table today.
The number of times I have had to correct tech-ish friends when they talk about "telnet-ing" into servers is frightening. All of them were relatively technology literate but either didn't do it for a living or got into doing it for a living "by accident". Think your physics major buddy who has only ever used windows on any computer that he owns.
You put people like that in the position to make a call, and I assure you you'll have an FTP server running somewhere in 5 minutes flat.
It's also the case that SFTP requires giving someone an actual user account on your UNIX box, and preferably knowing enough about how to set SSH up to restrict them to SFTP access only. If your server is much more valuable than the data and you don't trust yourself not to get SSH configuration subtly wrong, it's not terribly unreasonable to prefer installing an FTP server to adding a local user and giving someone else a password to it.
If Microsoft every had of built a decent client into Windows Explorer like MacOSX has (rather than the crufty, half baked one they ran with) then it could have been great. As it turns out, it is only really easy to access it through FTP-like programs (separate from Windows Explorer).
Having said that, we had pretty good experiences with WebDrive  allowing us to mount WebDAV directories in Windows. Also, Gnome does a pretty good job on Linux with GVFS .
See: http://codahale.com/how-to-safely-store-a-password/ for details.
Uh? Why? It is a useful thing to do. More than that, it is necessary (but not sufficient). There's a reason why all of pbkdf2, bcrypt and scrypt generate salts if you leave them to their own devices.
> See: http://codahale.com/how-to-safely-store-a-password/ for details.
You completely misunderstand the article.
If you use a common hash with no salt you can bet your britches the attacker will use rainbow tables!
It's also worth pointing out that rainbow tables aren't the only attack you are exposed to if you don't salt your passwords - it also prevents finding collisions, and massively slows down forward hashing attacks.
Which is why you need to not use a hashing algorithm designed to be fast, like SHA, but one designed to be slow, like bcrypt.
pwhash = md5("this is my salt" + password)
Good news, everyone: it will!