Mozilla's secure coding guidelines for web developers
wiki.mozilla.org
wiki.mozilla.org
Invalid login attempts (for any reason) should return the generic error message:
The username or password you entered is not valid
Registration form will show a specific error when you try to register username that is already taken. Password reminder form will show error when you request reminder for an unknown e-mail. Some websites even have AJAX APIs for checking validity of usernames/emails!
Because of that it's easy for an attacker to check whether username or password is invalid. Vague error messages make it only hard for the user.
I wonder how many emails scrapers have done of Forgotten Email pages.
2) Send a non-blocking request with a flag, eg "Good" "Bad".
3) Return message to user that email has been sent but can not confirm if the email is true for privacy reasons.
While yes, it can be down to a timing attack, the trouble is that this vector can be used against sessions, logins, etc. It can be a standard that Mozilla should adopt.
a correct site - and I have corrected dozen of them, and they work just fine does not give a specific error msg for password reminders either, or any other function.
so the generic message should be returned from every such function, and i'm pretty sure they talk about password recovery as well. (and again ANY such function should return a generic message)
mind you, its much easier to compromise a site when you can check the username and just have to crack the password. you can automate it easily as well.
ps: oh, look,next paragraph after what you pasted: "The following message should be returned to the user regardless if the username or email address is valid:" for recovery. Pretty sure you've seen it and voluntarily ignored it :-( mean mean mean.
If you don't want to use a CAPTCHA for regular signups, you can add one to the page dynamically when you see multiple registrations from the same IP address.
What about sites that let the user know his username is already taken using AJAX? Should this be avoided too?
I like zobzu's idea of using an email as login, though.
Of course, the downside is that you're slowing the user down. It's acceptable for the sites that choose to require valid email addresses: if you're going to go there you might as well get it done sooner.
You'd also be spamming potential victims, but that may not be that bad, as you'd also be alerting them.
EDIT: oops meant this to be a reply to the GP.
and if thats too annoying to implement use browserid.org
> Examples of Good Input Validation Approaches... Firstname: Letters, single apostrophe, 1 to 30 characters
First, I'm not sure if I should interpret letters as [A-Za-z] or something more inclusive of non-Latin characters. But anyway, why restrict this so much? What about spaces, as in Mary Ellen; dots, as in P.J.? Heck, why can't I use a hyphen or a number? Just because you might not try to name your kid Brfxxccxxmnpcccclllmmnprxvclmnckssqlbb11116 doesn't mean nobody else will (http://en.wikipedia.org/wiki/Naming_law_in_Sweden#Protest_na...).
Perhaps I'm not seeing the forest for the trees here, but when it comes to restricting input, it always seems there's a risk of "We can not accept that last name" behavior (http://www.cooper.com/journal/2009/09/we_cannot_accept_that....). If you're properly sanitizing/escaping on the way out, why be so harsh on the way in?
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#...
- The nonce for the hmac value is designed to be stored on the file system and not in the databases storing the password hashes. In the event of a compromise of hash values due to SQL injection, the nonce will still be an unknown value since it would not be compromised from the file system. This significantly increases the complexity of brute forcing the compromised hashes considering both bcrypt and a large unknown nonce value
- The hmac operation is simply used as a secondary defense in the event there is a design weakness with bcrypt that could leak information about the password or aid an attacker
With bcrypt alone, compromise of the password hashes still allows brute-force offline dictionary attacks. bcrypt means that each guess might take, e.g., milliseconds instead of microseconds, but an attacker has all of the information he needs to make offline guesses and check them against the compromised hash.
The hmac step means that an attacker who has the password hashes but not the hmac nonce effectively doesn't get any offline guesses. Assuming the nonce is e.g., 128+ bits, it'll be computationally infeasible for the attacker to guess the nonce itself, without which he can't verify any offline password guesses.
hash(password_plaintext + salt + site_salt)
> Email verification links should not provide the user with an authenticated session.
It always bugs me. The "forgot password" links only allows me to choose a new password, but does not log me, adding a extra step.
However, the price for not doing this is pretty high in terms of conversion, so as far as I'm concerned it's not a black and white issue.
If there's nothing particularly sensitive to be compromised (and that usually isn't the case at this stage), simple measures like rapidly expiring the verification URL and allowing it to be used only once is "good enough" for most sites.
There are no absolutes in security.
Aren't both of these equivalent though?
(I would think the point may be that a compromised email, doesn't provide access later. Both these scenario are equally vulnerable then?)
Ensure that a robust escaping routine is in place to prevent the user
from adding additional characters that can be executed by the OS (
e.g. user appends | to the malicious data and then executes another OS
command). Remember to use a positive approach when constructing
escaping routinges.
beside, even parametrized, you have to be careful. I'll remind you of the 2004 Safari handler exploit. Apple fixed the first exploit by using parametrized argument list. Woot. Next day, exploited again because some programs call execve on their argument list, for example ssh -o'ProxyCommand=exploit here' which is 2 arguments (-o and the complete proxycommand line including the exploit line).
This is valid for websites as well.
Thank you for this.
I'd suggest the use of Ghostery (works on all major browsers) on the client side, and on the server site, well, you know, not use any like button :>
These guidelines are a good example of what web developers have to deal with on a daily basis. Certainly not trivial.
I think this is a good argument for the existence of a suite/library that manages things like password storage, recovery, validation, etc. Integrating everything from using good salts and hashes to captchas and retry delays.
Half of the top 50 cracked Gawker passwords were 8 characters (and longer passwords were not exposed, due to the nature of the vulnerability). Since 8 character passwords are vulnerable to a known common weakness (in DES), this should be revised to:
Passwords must be 9 characters or greater
This will prevent your users from using passwords that are vulnerable to the DES attack if they reuse them on other sites.
But what if my password is the word "biological"? By knowing the first 8 characters, the attacker has drastically reduced the number of guesses that need to be made (assuming a priori knowledge that the password is shared between sites).
Also consider MD5(PASSWORD) and SHA1(PASSWORD). Those are both fairly common constructions for "secure password hashing" [note: they're not really secure] in web applications and both of those would yield up the entire plaintext password if an attacker used a brute-force or rainbow table attack.
If you're designing a secure web application, you can't make your goal to secure all the other websites on the Internet. Bumping the minimum number of characters to 9 wouldn't significantly impact the security of your users. If you're really worried about a situation where a user's password is disclosed, you should consider offering two-factor authentication options for your users.
And the guidelines specifically say "Blacklisted passwords should be implemented (contact infrasec for the list)" which indicates to me that known common passwords like '12345678' and 'password' will be disallowed (although we don't have access to the list).
My opinion (and we may have to agree to disagree on this point) is that adding one character to the minimum is not going to make a significant difference in application security. I don't believe it mitigates the danger of a leak of DES-encrypted passwords. If you're concerned about a scenario where a user's shared password on another site is compromised, your application can use two-factor authentication or mandate the use of strong pass-phrases instead of traditional passwords.
This is a financial institution.
All sites should have the following base password policy:
Passwords must be 8 characters or greater
Passwords must require letters and numbers
Blacklisted passwords should be implemented (contact infrasec for the list)
Yes. If a password is too weak and it results in a user's account getting compromised, the website gets the blame. Thus, the website mandates the password policy.
And depending on the site, weak passwords and compromised accounts directly impact other users. Imagine if eBay had no password policy and some of their largest sellers had their accounts compromised as a result; what impact would that have on buyers?
http://security.stackexchange.com/questions/6095/xkcd-936-sh...
Likewise, I assume they're keeping that list semi-secure to avoid black-hats/kiddies getting their hands on a list of really good passwords to throw into their cracking engine ruleset.
-Michael (@_mwc)
Example A field accepts a username. A good regex would
be to verify that the data consists of the following
[0-9a-A-Z]{3,10}. The data is rejected if it doesn't
match.
The variations of attacks are enormous. Use regular expressions
to define what is good and then deny the input if anything else is received.
In other words, we want to use the approach "Accept Known Good" instead of
"Reject Known Bad"Moral: account registration and authentication must use the same password normalization functions, and if you validate at auth time (which is pointless, but hey), the validation function must be the same as the registration one.
Better moral: just don't do silly things with passwords. Encrypt them and store them, accepting whatever the user wants to send you that's sufficiently long/high-entropy.
That said, it could confuse people. I'd suggest to fill a bug at bugzilla.mozilla.org to put a broader example, or to specify that you might want different characters in the known good list, specially for non-latin writing people, cause yeah, many would just copy paste it without thinking further.
Then there is unicode normalization. OSX might decide to encode "e-with-an-accent" as two code points, while Windows will combine them into a single code point. Users will not be impressed if they can't log in because their OS doesn't use the right encoding and the web site forgot to normalize.
I was actually wondering how the Mozilla guidance is different.