More on logins

Thanks for your comments. Scott writes in a comment:

Assigning things individually is only marginally more secure, given the fact that your example contains no server side validation of data or authorization. Almost invariably, your application would have some sort of administrative interface to choose set admins, and that action could be divined in the same way that the admin attribute could be. Granted, guessing that you post to /users/make_admin/1 to make an administrator is more obscure than guessing the user[admin] field, but we know better than security through obscurity.

Here's some more on logins:

 
When you create your own access control or modify generated ones, you have to keep in mind that MySQL requests are case insensitive by default, and thus at least user names will be the same though in a different case. MySQL provides a BINARY operator, which makes statements case sensitive, for example:

User.find(:first, :conditions => ["BINARY login = ? AND \\

BINARY password = ?", login, pass])

# finds the first user in the database which
# matches the login information case sensitively

This maybe desired or not, but you have to use the same method when signing up and logging in users, or user names might occur more than once with different cases.

Also if the login process failed, you should not present too much information as to why it failed. If you tell an attacker whether user name or password was wrong he can focus on finding the other part. You should also be aware of the possibility of brute force attacks on the login page. As a countermeasure you can save the number of failed login attempts on an account and disable the account or require to enter a CAPTCHA to log in after a certain number of failed logins.

Comments

[ma438zda]

c632t