Hi,
I want to create a login form, I wonder what combination of information I should collect from the input fields for a better security -
email + password
or
username + password
another security issue, should I encrypt the password using sha1() for the better security? or can I save the password, such as 12345, as it is in my database? what risk I am taking if I don’t encrypt the password?
Many thanks,
Lau
are you directing your opinion just to me or to felgall as well since he was suggesting timeouts as a form of captcha and to everyone else that uses one form of captcha or another…
I didn’t say that timeouts are not a form of captcha, but I believe some forms of captcha are better than others.
I am going to continue using captchas on registration and email forms so I’m not sure what point you are trying to make.
Just to be pedantic, a CAPTCHA is a “Completely Automated Public Turing test to tell Computers and Humans Apart”
Any and all suggestions in this thread are CAPTCHAs, image? timeout? session vars? logic/math questions? All serve the same purpose. Defend what you need to. Perhaps the attacking bot has several million IP addresses at their disposal, and a sophisticated image CAPTCHA algorithm (e.g. Turk), or perhaps none of this is necessary as you’re not using a popular CMS.
Another method is to allow a certain number of failed attempts, and if that threshold is breached, lock the account for x minutes. Reset to zero on successful login.
Any valid user would either get it right or use a forgot password tool within say 5 attempts, especially if they know they are about to be locked out. I believe several linux brute force protection packages work on this premise.
On the note of username vs email, sometimes it is necessary to show the username publicly to create some accountability (think auction sites, especially seller names).
Nowadays I prefer emails over usernames for login purposes, the reason being that people often change their email address, and without thinking about what address they are using at the login stage, are more prone to forget to update it, potentially rendering their account useless if they forget the password and cannot receive email to their old address.
That’s one reason why I said I don’t normally use email addresses.
Regarding using usernames, unless a client specifies that they are viewable by other users once they have logged in (like you can on this type of website) then I don’t allow users to see other registered usernames.
The only place they will know a username exists is when they try to register a new username. If the name they want to register already exists then they will get a message saying so. But I don’t see how you can avoid that if you have unique usernames.
Depending on how robust your captcha is and the nature of your website, you can stop spammers/hackers from hacking into your database by virtue of the fact that it becomes totally time inefficient for them to continue trying to break through your captcha.
Why not accept either user name or email address as the login? I prefer sites that do this since a username is convenient to a frequently used site, but an email address is unlikely to be forgotten.
I see time delays as just another layer of difficulty you can add to your security but not as a total subsitute for captchas.
If you don’t have a captcha to distinguish between human and machine then essentially all yuo are doing is delaying the inevitable if someone is committed to breaking through.
Even captchas are not a 100% defence but are still pretty good imho if implemented properly. They to are just another layer of defence (with their pros and cons just like any other security measure) and whether you use them or not boils down to your security requirements and the way you implement them.
Sorry, not addressed at anyone in particular, rather addressing the whole idea of a captcha being that stupid picture you have to type out.
The point I’m trying to make is: Only use what you need to. Do you really need an image captcha? is there a better method? alternate method?
Neither will give any better security, they are both essentially the same.
Firstly I normally use captchas only on registration and email forms. I don’t have them on login forms (see post no. 7)
Also, I’m not saying there is anything wrong with time delays between login attempts and/or lockouts. I lockout the user after 3 failed login attempts as well.
But I still believe that without some sort of captcha in addition to time delays and lockouts you are still more vulnerable to being broken into than if you had some sort of visual or audio captcha as well.
I accept that what you are suggesting has a low probability that someone will break through it. But I think having a captcha either on its own or in addition to what you suggest, at least on registration and email forms, lowers the probability of being broken into even less and for me there is an insignificant risk of loosing a tiny number of legitimate visitors with the trade-off being knowing my database is secure from being hacked.
I’m not going to stop using captchas so I am not sure what point you are trying to make about the way I do things.
If other people don’t want to use captchas I don’t have any issue with that.
maybe slightly off topic, but related to some extent - an interesting read on working out the strength of passwords
That’s the key point right there.
Yes it might break through on day 1 or still be trying in 5000 or whatever years. But it also could break in on the 2nd, 3rd, 4th etc etc day.
With a robust captcha it won’t break in at all. Sure, there is a possibility of loosing a tiny number of legitimate visitors but I see that as a very small price to pay knowing that the contents and integrity of my database is secure.
But then again others might see it differently based on the nature and purpose of their website. You really should evaluate the need for a captcha on a website to website basis.
The problem with any form of CAPTCHA is that along with the bots it also blocks a percentage of real people as well. The more secure that the CAPTCHA is at blocking bots, the larger the percentage of real people that will be blocked as well.
If you require a 30 second delay between attempts at loggin in then a bot can only try 2880 possible passwords a day and so can only check just over a million possible passwords in a year. If there are several billion possible passwords to check then it will on average take a bot thousands of years to break in. Now it might get lucky and break in on the first day or it might still be trying possible passwords 5000 years later. Sure someone could be committed to breaking into your site but if a brute force password attachk is going to take an average of thousands of years per account then that effectively rules out that approach. That’s also assuming that they manage to figure out what the delay that you have built in actially is since if they try passwords any quicker than your delay then they will never break in using that method.
The delay in itself is a fairly robust unobtrusive CAPTCHA. To make it even more robust you could have it lock the account completely if there are more than a set number of login attempts within a given period (say more than 50 within the last 24 hours) since a real person isn’t going to need to try to log in that many times.
Unobtrusive CAPTCHAs have the advantage of being far less likely to block real people from being able to log in since they work off of the difference in behaviour between a person and a bot rather than assuming that something is going to be readable by a person and not readable to a bot (and I’ve seen manyimage CAPTCHAs where the text is likely to be able to be read by a bot with OCR capability - the ones that the OCR can’t read can;t be read by lots of real people as well). Also unobtrusive CAPTCHAs don’t have accessibility issues.
Finally those CAPTCHAs that are visible in the page are going to be broken long before any unobtrusive CAPTCHAs behind the scenes (such as the delay and lock I mentioned) since the bot writers know that te visible CAPTCHA is there to need breaking whereas they have no way to tell if you have a delay built into your code or how long that delay is and so it is just about impossible that they’d consider trying a 31 second (or whatever) delay between attempts in the first place so as to even have a chance of breaking the password in an average of several thousand years. Most would run the tests too quickly and would therefore only ever get in if their first guess was right.
The whole point of a delay CAPTCHA is that the bots don’t think to wait so many seconds between attempts whereas a person will take a certain amount of time to type in their next attempt and so the time difference between attempts tells you if it is a person or a bot .
or an alternative could be to choose a username that is very likely to be unique and use it wherever you need to register a username.
Unless you have a relatively large number of accounts spread over the www you will most likely be able to use the same username on each account - but obviously use different passwords for security.
another reason I prefer to not user email addresses for login is because unless you have a “remember me” button, users will need to type in a relatively long string of chars, compared to an average length username.
In addition to this, it stops people registering with the username “John1986” because “John” was taken then subsequently forgetting what their username is because they couldn’t get the one they actually wanted. Also, on large sites people can frustrated during registration trying over and over finding an available username. Some will give up, others will end up with a username they don’t really want.
I would also recommend hashing the password for the reasons expressed by felgall.
Whether you use an email address or something else for the username is pretty much the same because they should both be unique. But unless a client specifies otherwise, I don’t use the email as the username mainly because email addresses might be easier to guess if you know someone and have a reasonable idea of what their email address could be.
You can actually do this right at the network level and I recommend one to do it. Getting several connections within a short span of time from the same address is a known attack pattern. The first line of defense should be a firewall, right as the connection enters the building, that is setup to disconnect any connection that hits this rate limit. No human user would have several connections hitting the server in such a short amount of time.
thank you so much for this explanation! I am now hashing the password!