Hello,

I'm now building a website using PHP, HTML and CSS and I want to make a member system. That is not so difficult with PHP and MySQL, but now I want to crypt the passwords, the emailadres and the names, when they send it to me (server) or when my server send it to them. Is there a way I can do that?
It is a necessary part of the member system, because the law in says that you must crypt all personal data send over the internet.

Thanks in advance,

oguh

I'm not an expert, but I think if you set everything to https://, it would encrypt the data for you. Otherwise, there is this that I just found, would be it kind of like what you need? http://www.techrepublic.com/article/protect-sensitive-web-site-data-by-encrypting-information-with-mysql/6124013

I believe you are looking for the words "encrypt" and "decrypt"

Also, which set of laws are you worried about?



https will protect the data coming to and from your server, but it must be enabled on your server to work.

For an extra layer of protection, you'll want users' passwords to be hashed (MD5 or some other hash type) before they're stored in the database. When a user inputs a password to log in, the inputted password should be hashed via the same method and compared to the hash stored in the database.

This (I assume, anyway) is to render the situation such that (A) if somebody were to read the data going to the server from the client, they wouldn't be able to interpret it as anything useful and (B) attempting to change passwords through SQL injection or other database hackery would fail unless they're familiar with how the site hashes/encrypts/whatevers the passwords.

Also, yes, https:// is a good idea, although I don't think it's all too necessary unless you're handling super-sensitive information like phone numbers, SSNs, or other such personal identifiers.

Of course, some people are idiots who use the same password for everything, but isn't that what the hashing is for?

and has been for the last half decade. And for that matter, it was shown to be technically insecure almost a decade and a half ago.

MD5 = no thanks. Choose a hash that isn't broken.

Ah, I was unaware of that. Thanks for the head's up, Elf.

In my own opinion, however, I don't think it would matter so much for a website that probably won't contain any purposeful sensitive information or be highly trafficked (no offense, oguh). Is somebody really going to bother breaking MD5 to muck around with a website that nets them nothing?

c.f. my own website getting hacked a couple of years ago by a script kiddie.

Bad security is worse than no security. Seriously, MD5 is broken, just don't use it. Use any number of still un-pwned hashes (such as SHA1, or even better SHA-256).

No, don't use SHA-1. Use SHA-2 and that only until a winner is selected for SHA-3.

For transmitting things like form data encrypted over the internet, you need to use HTTPS. If you did something like encrypt the data via Javascript clientside before sending it to the server without Secure HTTP, you'd be wide-open for a man-in-the-middle attack where an attacker simply intercepted the encryption key outbound to the client. For storing user data securely in a database, you should hash (one-way "encryption"), not encrypt, their passwords. For a deterministic hashing function, you can hash a candidate password and compared it to the stored hash to see if the user entered the correct password for something like logging in without storing the original password.

Sorry for the late response, I was working on some other projects.
The law in Holland says you must crypt all personal data on the internet, what means you must use a kind of SSL to protect the server-client connection. When I use one-way hashing the personal data is not protected in the connection. And when I visit my site only with https:// at the beginning the data isn't been crypted in the connection, is it? I thought, that I then must buy a SSL sertificate. Are there any free substitutes of SSL?

oguh

https is, by definition, encrypted in transit, so that's fine. As for getting a certificate, you can generate a self-signed certificate and use that just fine (and costs nothing), but since it's self-signed most browsers will require users to choose to accept the certificate.
If you were to purchase a certificate, it would be signed by a well-known CA (certificate authority) and allow the user's browser to verify that your site is indeed the site it claims to be. With a self-signed certificate that's not possible, but you still get SSL on the connection, which is all the law requires.

Short version: you can self-sign for free, which gets you the requisite encryption in transit, but it inconveniences your users a bit and leaves the way open for man-in-the-middle attacks.

To clarify again, SSL certificates themselves are free, but if you want a verifiable certificate, you have to buy it on a yearly basis from a Certificate Authority.

Unless you used public-key encryption in some form, such as by having the client send its public key to the server and the server sends the encryption key to the client, encrypted with the client's public key. Of course, it's much better and easier to just go with HTTPS, which handles all of the low-level encryption details transparently.

Definitely, especially since most browsers don't expose some kind of public/private key interface to Javascript to the best of my knowledge, or even provide access to some client-secret and client-unique data that could be used to generate a private key.

Here's a good random-number generator that you can adapt to Javascript for generating a private key: http://xkcd.com/221/

That's about the security of OpenSSH until not long enough ago, right? But unless I misunderstand something, shouldn't the private key be reproducible without any storage? I guess putting the private key in a cookie isn't the total end of the world, but it still feels like a bad idea.

This is a terrible idea given current browsers (as Kerm pointed out). public-key encryption requires public key infrastructure or have fun with those MITM attacks.


But so is putting anything exploitable in a cookie.

Thanks for all your help.
I'm think I'm going to use SSL.
oguh

Best of luck with that; let us know how it works out for you!