What attacks can be directed on a registration page

Question

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?

Answer 1

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.

Answer 2

Use recaptcha or asirra to avoid automatic submission. That should stop the bots and script kiddies.

To stop hordes of humans from submitting spam (via mechanical turk or anything like that), log each attempt in memcached and as soon as you reach a maximum submissions from the same IP in a given period of time, block that IP for a few minutes (or hours, days, whatever...).