New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I already did. I advise actually reading what I say.
EDIT: Nice how you slipped in 'account numbers' there while I never said anything about account numbers. In most cases an account number is something you can do things with even if you do not have a login. So no, what I said does not go for those account numbers.
Then you should have no issue explaining it yourself, right? If it's so obvious?
Not really. Bruteforcing login page costs nothing. Unless you're using random 120 characters email as well, it's very efficient way. It takes a minute to adopt the bot to your page, you can let it run for years and if you're able to retrieve just one email a day that's enough. How is that not efficient?
It's really a bad practice to allow someone to retrieve your users personal information from your site, even if "there is a pretty good chance" it won't happen. It's not your goal just to protect someone's password and access to their account, you should protect everything.
And seriously, because all big guys are doing it is not valid reasoning? The fact they have millions of users, thousands or people working on it and 10+ years of experience does give certain weight to their decisions.
Anyway, error message telling you if username or password is wrong is not really helpful, most of the time it will just add to user's confusion. If you're running a fairy large site with a few hundred thousands users or more there is a pretty good chance they'll end up trying to log into someone else's account. From my experience it happens much more often than "I have no idea what my username was and I lost access to my email".
Okay, again. This is why you have bruteforce protections that adequately protect your users. Stop trying to make up bullshit reasons for going the easy and lazy route, by obscuring error messages, and instead implement real protection. Seriously.
No, it isn't. This is fucking security we're talking about. If you implement security, you should know what the fuck you are doing and why you are doing it. If you don't, stay the hell away from doing any development requiring security whatsoever, because you're only bringing users in danger.
No, it doesn't - see above. Not to mention that there is no indication that their decisions have anything to do with well-reasoned security protocols - you are assuming that no other variables played a role in their decisions.
Assumptions are a very very very bad thing in security.
Of course you are totally right, that's why the one documented experiment into the effectiveness of specific error messages disagrees with you. Oh, wait.
Seriously guys, I'm getting tired of this bullshit. If you want to implement proper security, then fucking think about it instead of just assuming that "what the big guys do is great". You are a danger to your users. Reasoning like yours is the reason large sites get owned every single day.
I gave you my reasoning and all you say is "it's bullish because I say it is". Do you even read what everyone else is saying?
Where did I say (or anyone else) it's good just because big guys do it? You haven't given a single good reason why would you allow your users email to be retrieved by someone else?
Care to elaborate?
You are a danger to your users if you think bruteforce protection is all you need.
Gladly.
Your mindset that "because the big names do it, it's a good idea" is the fastest way to implementing a horribly broken and dangerous system, because you're not thinking about it and really have no idea what you're doing. Ask how well that worked out for Sony and, ironically, MailChimp (see the referenced blog post where they basically found out they were doing it wrong all the time).
Did I say bruteforce protection is all you need? No, I said it was what you needed for this particular aspect of security.
And I said it where?
No, you said bruteforce protection is all you need to protect users for this particular aspect of security. You are allowing a persistent attacker to gain access to someone's personal information stored on your site using your site's facility. That's not acceptable in any way.
@vedran: "And seriously, because all big guys are doing it is not valid reasoning? The fact they have millions of users, thousands or people working on it and 10+ years of experience does give certain weight to their decisions."
Harvesting e-mail addresses from a login page really is inefficient. Even making a list of all common first name & last name combinations that are seperated by "." or "_" and adding "@hotmail.com" or "@gmail.com" is more efficient for spammers.
If I'm reading that correctly, double hashing increases the chances of a collision, meaning that if my password is "password", an attacker may also find a different input like "jhfj74dfjj6" that leads to the same hash after a "thousands of sha256 rounds" algorithm runs?
If that's the case, that's not as bad as I was at first thinking (although it's still not good of course), since it only means an attacker could sign in as a user with the collision generating password of "jhfj74dfjj6" at the compromised website, but they can't then go and use it at another website the user frequents because even if the user was stupid and used the same credentials at Gmail, the attacker still doesn't know that the REAL password is "password".
Unless I missed something?
Apart from security not displaying valid e-mail addresses has a privacy aspect. If i knew someone's e-mail address (e.g. from their LET profile or LEB post) i could find out what sites they use, what kinds of porn they like , on which forums they are registered etc etc.
lesbian mostly
Not really worth the effort though. And for sites you don't want other people to know about, use a fake/alternative e-mail.
That's relative. It's not worth the effort for someone to do that with my email address because I'm Joe Nobody, but it could be scandalous to somebody with more social or political importance.
My personal opinion is that login error messages should be vague as to why the login failed, if for no other reason than because it doesn't seem to be necessary to be specific.
In my experience when a user gets a login denied message, they go on to try a different email with the same password. So they don't need me to tell them "your email is invalid", most of them are already assuming that's the problem, and I'm assuming that's because most users use the same password on every site they visit so they know the password is not the problem.
Worst case they can't figure things out, and they move on to the "forgot your password?" page. If the email is the problem, then I send a message to that account telling them so. If the password was the problem, then I send them reset instructions.
Basically it comes down to this: When I see a website with a "forgot your password?" feature that emails me my password, I run away screaming. But when I see a website with a "your email address is invalid" login error I may cringe a little, but it's not the end of the world.
Hi Everybody .. thanks for reviewing my last login script , now I have written the Contact Us script .Please have a look at it and let me know in case of vulnerabilities (especially SQL Injection) or if i have messed up somewhere ..
http://pastebin.com/M899AaeR
First, use PDO. Second, probably not a good idea to mix that much HTML and actual code.
Why are you connecting to your database? You don't need to do that for a contact form. Remove that code and you won't have to worry about SQL Injection on that particular page.
I myself like to use this combined with HTML5 input type="email" to check email addresses.
@joepie91 .. thanks for such an elaborate way to explain with code snippet ..
Below is another link .. not sure how effective it is as compared to your method .. but this looks promising as well ..
http://crackstation.net/hashing-security.htm#phpsourcecode
That blog post is not the best defense of your argument IMO...they decided it wasn't a risk to add specific error messages for two reasons:
1) They already leaked that information elsewhere anyway
2) Everybody else is doing it, so why can't we
Again, IMO, the proper reaction shouldn't have been "we already leak it elsewhere, so let's leak it here too", but should have been "who the hell decided it was OK to leak that information in the first place, let's go find a better way to do that".
And as someone rightly pointed out earlier (I think it was you actually, but I don't remember for sure), just because everyone else is doing something doesn't make it the right thing to do.
I totally agree that it barely adds any security at all, in fact I'd argue that the privacy issue raised above is a greater concern, but either reason is still enough to not have specific error messages.
It's definitely not end of the world stuff, but it doesn't hurt anybody to do it that way. Mailchimp makes the argument that it improved the user experience, but did it really? They didn't provide enough information to know for sure. Yes they state a 66% drop in failures between the two time periods, but was there an equivalent (or worse, greater!) drop in login attempts? Also, what percentage of attempted logins are failures to begin with...did they reduce it from a tiny fraction to a smaller tiny fraction?
Even if the reduction turns out to be significant, it's still a dangerous game to start cutting corners with security to make the UX team happy...
based on the joepie91 code and taking the reference of PHP crypt manual . i have written the below quick php script --
<?php function cryptpassword($input) { $salt = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM)); //$hash = crypt($input, "\$5\$rounds=50000\${$salt}\$"); $hash = crypt($input, '$5$rounds=50000${$salt}$'); return $hash; } $cryptedpassword = cryptpassword('test123');//enter pass which you want to encrypt echo $cryptedpassword; ?>It returns s below --
$5$rounds=50000${$wnklXJLpO.n6UXPwNPcZmLjSRZP0vOgbqTn3.rIplM4
what "$5$rounds=50000" is doing in the output , if yes then do we need to store the whole above generated string in db or just without the "$5$rounds=50000" part.
Am i doing something wrong here ?
Store the whole string. It gives you the ability to set a higher number of rounds later on when 50000 becomes easy to decrypt.
@wunderbar ..
so i should be storing the complete string as "$5$rounds=50000${$wnklXJLpO.n6UXPwNPcZmLjSRZP0vOgbqTn3.rIplM4" into the database
Also while generating the string which line should I use, as the first line has escape charcter as \ before every $ --
//$hash = crypt($input, "\$5\$rounds=50000\${$salt}\$"); // <<<--- AM I SUPPOSE TO USE THIS $hash = crypt($input, '$5$rounds=50000${$salt}$'); //<<<--- OR AM I SUPPOSE TO USE THISAnd then later on while authenticating , shall I be using the below code --
`$hashed_password = "$5$rounds=50000${$wnklXJLpO.n6UXPwNPcZmLjSRZP0vOgbqTn3.rIplM4" //Taken from db
if (crypt($user_input, $hashed_password) == $hashed_password) {
echo "Password verified!";
}`
Now I am successfully able to generate the crypted string .. now I want that generated string to be compared with user given input --
<?php /*This script is used to verify whether the crypt string generated from generatecryptpassword.php script matches with the new crypt string of the user input password Ideally $hash value will come from db , but we have taken it directly from the generatecryptpassword.php script . Also note that we need to escape the $ as \$ before comparing*/ $user_input= 'test123'; $hash = '$6$rounds=50000$86f50a6ac3d0839a$6oapcEjXqL5FsAS6Uj6LUeUxHhW3dH1/krfFwQYCOzg8qAHlPSu/Cvtq4p5XSzmi8yQ1g9F3/syAEhlVXKbQS1'; $newhash= str_replace('$','\$',$hash); echo $newhash . "\n"; /* To verify the hash: */ //$newhash="\$6\$rounds=50000\$86f50a6ac3d0839a\$6oapcEjXqL5FsAS6Uj6LUeUxHhW3dH1/krfFwQYCOzg8qAHlPSu/Cvtq4p5XSzmi8yQ1g9F3/syAEhlVXKbQS1"; echo crypt($user_input, $newhash) . "\n"; //optional if(crypt($user_input, $newhash) == $newhash) { echo "Password is correct!"; } else { echo "Password is invalid"; } ?>The problem over here is that when I am manually changing '$' to '\$' then things are working perfectly , but when I doing it through str_replace fn , it doesnt works and the final hash het generated a new one as below ---
##php ./comparecryptedpassword.php
\$6\$rounds=50000\$86f50a6ac3d0839a\$6oapcEjXqL5FsAS6Uj6LUeUxHhW3dH1/krfFwQYCOzg8qAHlPSu/Cvtq4p5XSzmi8yQ1g9F3/syAEhlVXKbQS1
\$0lXFe./5bns <<-- this should be the original crypted string . but its some other value
Password is invalid
any pointers ..
This one
Yes, that should work
No need to alter the hash from the DB