What attacks can be directed on a registration page
forms, security
Solution
Use HTTPS, i.e. a combination of HTTP and SSL to provide encryption and secure identification of the server when submitting sensitive data like a password. The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted.
Problem
I have a website registration page, and I'm trying to compile a list of what I need to do to protect it. If you know of an attack, please name it, and briefly describe it preferably with a brief description of its solution. All helpful answers/comments receive an up vote. Here's what I have in mind so far: (and adding what others are suggesting. Phew, adding other input turned out to be lots of work, but please keep them coming, I'll continue adding here) - SQL injections: from user input date. Solution: prepared statements. [AviD] "Stored Procedures also provide additional benefits (above prepared statements), such as the ability of least privilege on the DB" - Good point, please explain. I thought stored procedures were THE SAME as prepared statements. What I mean those statements were you bindParam the variables. Are they different? Not hashing the password before entering into db. Solution: hash passwords. - [AviD] "re Hashing, the password needs a salt (random value added to the password before hashing), to prevent Rainbow Table attacks and same-password attacks." - "the salt used should be different for each user." - Good point, I have a question about this: I know salt should be random but also unique. How do we establish the unique part to counter against the same-password attack? I've been reading on this, but didn't get a clear answer on it yet. - [Inshallah] "if you use a long salt, like 16 chars for SHA-256 ($5$) then you don't really need to verify its uniqueness" [Inshallah] "Actually, I think it doesn't really matter whether or not there are some conflicts. The salt is only for prevention of table lookups, so even a 2 char salt will be a (small) gain, even if there are conflicts. We are not talking about a cryptographic nonce here that absolutely mustn't repeat. But I'm not a cryptanalyst" - Good point, but does anyone have disclaimers on this point? Dos attacks?! (I'm guessing this applies to registration forms too) [Pascal Thivent] "Use HTTPs when submitting sensible data like a password." "for man-in-the-middle attacks, provided that adequate cipher suites are used " - What are the "adequate cipher suites" being referred to here? [Koosha] "Use HTTPs or encrypt passwords before submition with MD5 and Javascript in clientside." - I don't agree to MD5 and don't like encrypting on client-side, makes no sense at all to me. but other input welcome. [Dan Atkinson] Exclude certain usernames to prevent clashes with existing pages that have the same name (see original post for full answer and explanation) - [Koosha] "limit allowed characters for username.for example alphabet and numbers, dash(-) and dot(.)" - Please explain exactly why? - [Stu42] "Use Captcha so that a bot cannot automatically create multiple accounts" - [AviD] "There are better solutions than captcha, but for a low-value site it can be good enough." - @AviD, please mention an example? [rasputin] "use e-mail verification" [Andrew and epochwolf] xss attacks - Although I don't agree with Andrew and epochwolf to simply filter < and > or to convert < to &tl; and > to >. Most opinions suggest a library like HTMLpurifier. Any input on this?