OK, please educate me. (Take me as a model web developer.)

I occasionally quickly hack some stuff together in php/javascript/html. I never figured out what should I do exactly to actually set up Apache to work with https, without needing to pay some money to some authorities.

I just have a simple LAMP server and I don't really understand Apache. How do I make it "https"?

And, upon re-reading my other answer and noticing it came out far snarkier on screen than it did in my head… Sorry 'bout that…

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)

For the sake of completion:

http://en.wikipedia.org/wiki/Server_Name_Indication#No_suppo...

This looks very good and easy to get it working. Will try next time, thanks!

You can use mod_ssl: http://onlamp.com/onlamp/2008/03/04/step-by-step-configuring... . Other good resources are an easy search away.

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/...).

tptacek explained to me once how using a self-signed certificate (or more to the point, trusting it) is a bad idea: http://news.ycombinator.com/item?id=2376644

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.

Though using self-signed certs during development is a perfect way to test https without shelling out for a CA signature.

OK, please educate me. (Take me as a model restauranteur.)

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?)

Because most people grow up knowing how to use dishwashers, but not knowing how to use SSL. Until we get to that point, we should focus on educating and informing people instead of snarking at them and hoping they get shut down.

The OP's (parody) comment is not about using dishwashers, but rather about dishwashing without using any detergent despite knowing that detergent is to dishwashing as SSL Certs is to https ...

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.

A simple way to side-step the issue entirely is to use an OAuth provider you trust.

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/

That can't possibly work, right? If a user accesses my website over unsecured HTTP, gets sent to an HTTPS DailyCred (or other OAuth provider) site to log in, and back to my unsecured HTTP site, they're still as vulnerable to man-in-the-middle attacks as if the OAuth provider didn't use HTTPS.

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!)

All of our inbound links and API calls from our clients are https from the get go. However, you are correct that a man-in-the-middle could rewrite the http website of someone using us to change the links to http from https and then perform a man-in-the-middle attack on that request.

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.

Don't ever tell people to use OAuth as an 'alternative'

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.

Unfortunately you do have to pay some money. Godaddy offers certs for 12.00 USD a year, which is probably less than you're paying to host the site.

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.

> Unfortunately you do have to pay some money. Godaddy offers certs for 12.00 USD a year, which is probably less than you're paying to host the site.

Wtf guys? Didn't we /just/ do this about GoDaddy? Just say NoDaddy.

free certs: https://cert.startcom.org/ or https://www.startssl.com/

If you don't want to worry about buying certificates and configuring webservers for HTTPS, check out CloudFlare. It's a bit expensive ($20/month for the first site, $5/month for additional sites) if all you care about is SSL, but they offer a lot more than just SSL:

http://www.cloudflare.com/

http://blog.cloudflare.com/easiest-ssl-ever-now-included-aut...

If it's for your own development work, Debian/Ubuntu will generate a self-signed SSL certificate when you install the package `ssl-cert`.

https://www.startssl.com/ There you get free certificates, along with other instructions given, you're free to go.

I think at this point, I think the software community at large is responsible for not solving this problem once and for all. It's clearly preferable to trust each OS/Browser vendor rather than trust each and every web site.

d) To not keep 100K users' passwords in a public FTP server :)

I'd take that further. Is there any good reason for anyone to run an FTP server (public or otherwise) in 2012?

If you want to have a shared folder that you share between people you trust, it's still the simplest solution. It's very low-level, but it works.

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 don't buy that it's "the simplest". Just about every major Linux distro ships w/ SFTP enabled out-of-the-box. How is installing an FTP server easier than just using the built-in SFTP server?

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.

I find that positive attitudes towards FTP often seem to correlate with positive feelings towards Telnet, and both seem to correlate with "Not really that comfortable with Nix"*.

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.

I believe that random Windows authoring software is vaguely more likely to have FTP built in than SFTP. (But finding good SFTP software for Windows, e.g. WinSCP, is not hard, so this is not much of an argument.)

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.

oh sure, SFTP is better, I thought we are comparing FTP/SFTP to DropBox and the like

I usually have an internal TFTP server set up and laying around somewhere. A lot of embedded devices provide simple support for updating their firmware over TFTP.

Engineers and scientists have large datasets to share. Gigabytes. Terabytes. FTP can handle it.

How do you dir on http?

WebDAV [0]

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 [1] allowing us to mount WebDAV directories in Windows. Also, Gnome does a pretty good job on Linux with GVFS [2].

[0] https://en.wikipedia.org/wiki/Webdav [1] http://www.webdrive.com/products/webdrive/index.html [2] https://en.wikipedia.org/wiki/GVFS

If this is your problem, FTP is not your answer.

Which makes me wonder why approximately everyone has a parser for the common FTP directory listing formats, but I'm not sure I've seen any HTTP client that parses Apache mod_autoindex output or the other big servers' equivalents.

I am not too well-versed in this sphere, but I would also require salting passwords when hashing. It obviously won't help if your database is compromised, but will protect your users (and your database) against the effects of leaks such as these.

One of these days we will shut down the "Salting password hashes is a useful thing to do." meme from 1994.

See: http://codahale.com/how-to-safely-store-a-password/ for details.

> One of these days we will shut down the "Salting password hashes is a useful thing to do."

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.

It's implicitly understood by everyone who cares about this topic that salting is intrinsic to KDFs. I.E. by the time you've read through, and understood http://codahale.com/how-to-safely-store-a-password/, you understand why "salting" your password gains you nothing, because rainbow tables are no longer particularly relevant to cracking passwords. And yes, while there is salting inherent to KDFs, that's not the major feature of them, but an assumed implementation detail.

> rainbow tables are no longer particularly relevant to cracking passwords

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.

Negative on that. Not all algorithms produce the salt internally like bcrypt does--programmers must still be careful to supply a sufficiently lengthy random salt as input to PBKDF2, for example. Labeling folks who know this as stuck in the past or ignorant is a mistake.

Of course a salt will not make a single password harder to attack. A salt will however force you to attack passwords "one at a time" by making precomputed hashes useless.

Yes, but you can attack them one at a time at astonishing speed these days.

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.

There's a reason key derivation functions like PBKDF2 and bcrypt still require a salt as an input.

And there's a reason why high-level libraries like bcrypt handle salt generation and storage internally: if they didn't, people would screw it up. It's amazing how many people blithely use some crazy scheme like

    pwhash = md5("this is my salt" + password)

Progress in password hashing security is primarily progress in making things trivially foolproof and then hectoring people into using them.

Doesn't this crazy scheme protect against brute force when only database is leaked, and "this is my salt" remains secret?

> It obviously won't help if your database is compromised

Good news, everyone: it will!

No, it won't. They can just write a new password + salt in the db and get in as that user.

Well, we need to define the attack if we're going to talk about what will and won't help. Generally when we talk password security, we assume the attack is to discover a large number of users' passwords, not to spoof as one. Additionally, it's more common to get read-only access to the data than it is to be able to execute arbitrary queries against the DB.

But maybe that's not want you want to achieve?

Can we amend c) to mandate bcrypt, scrypt, or PBKDF2 with a sufficient work factor that is reviewed every 12 months?

I wonder why the website package even wrote a log that included plaintext passwords. That's not IEEE's fault, except perhaps a lapse in judgement to use whatever opensource package.

Can you send MD5 encrypted passwords over HTTP? Can you send passwords over websockets?

It's perfectly possible to use md5 to hash a password in Javascript before transmitting it by HTTP. There isn't a huge security benefit to doing so, however.

Only doing that won't help. You might as well be transmitting the password, since someone can just copy the hash and then it would be equivalent to having the password. (Also known as a Pass the Hash attack, http://en.wikipedia.org/wiki/Pass_the_hash).

Each website could have a salt. The issue is, if it's not a secure connection, it's vulnerable to hijacks.

You can send a salted md5 password, which is how I implemented it years ago. The salt is supplied by the server and attached to the session.

The right way to do that is Digest authentication, which is a challenge-response mechanism (so you never actually send a password or something equivalently stealable). I call it the right way mostly because it's built in to just about all servers and clients; doing it over HTTP is still not a terribly good idea.