Re: Re: Do you trim() usernames and passwords?

From: Date: Thu, 30 Dec 2010 00:45:25 +0000
Subject: Re: Re: Do you trim() usernames and passwords?
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.general 
Request: Send a blank email to php-general+get-310367@lists.php.net to get a copy of this message
On Dec 29, 2010, at 6:52 PM, TR Shaw wrote: > > On Dec 29, 2010, at 12:56 PM, Joshua Kehn wrote: > >> On Dec 29, 2010, at 12:37 PM, tedd wrote: >> >>> At 11:06 AM +0200 12/29/10, Dotan Cohen wrote: >>>> Also, change them {passwords} frequently. >>> >>> I've always wondered about that -- if your password works, then why change it? >>> Where's the logic in that? >>> >>> From my perspective, it looks like "Hey, the crackers have not been able to crack >>> this, so let's give them another chance". That doesn't sound logical. >>> >>> There are things we "think" are right, but is this practice supported in some >>> way that's provable? >>> >>> Cheers, >>> >>> tedd >>> >>> -- >>> ------- >>> http://sperling.com/ >> >> An attacker manages to obtain the hashes and starts an attack. You change your password. >> The attacker now has to restart the attack. >> >> Changing your passwords prevents an attack from continuing past the length of time between >> password changes. >> >> Also if they _have_ managed to crack the password changing it forces them to crack it >> again, thus also limiting the time the account is compromised. > > > Gosh. Think about it. Lets not take the "your machine is compromised case" and/or > your password is moronic and/or you are not passing your password cleartext. > > So the threat is external. Now there are 2 types of external: one in house and one on the > 'net. > > The one in house is simply detected by an IDS like snort looking for very rapid login attempts. > Slow walkers are no risk at all. Further if your password is computationally hard your GigE LAN is > not fast enough to support cracking a computationally hard password before you retire. So there is > no threat that your computationally hard password will be cracked so your password is safe. > > For a 'net threat, the bandwidth is even more constrained so you could live 9 lives and > still not have your computationally hard password cracked. Further, log checking at the firewall and > on internal machines can easily detect cracking attempts. I detect about 4 per day on our > mailserver looking for pop logons and about 25 a day against ssh where we don't even use > passwords. ftp is not used. > > So an external threat against your machine as defined above, is not a risk. > > So now lets look at the case where there is malware on your machine which will try to brute > force your computationally hard password and is smart enough to use your graphics engine to > increased computational power. Folks at MIT and Carnegie Mellon have already numerically proved > that a 12 character password is not crackable using brute force in any reasonable timeframe. In fact > an 8 character one has strength of years. I would contend that using that much power will make its > existence known to you and coupled with the fact that you restart your computer every now and again > and that you run an antivirus periodically that will eventually find it even if you don't > notice the slow down. > > As you can see, cracking a password on your machine is so fruitless that no one would even try > to since if you have access to the machine a keylogger, for example, is faster and more reliable. To > thwart this you might want to run tripwire or equivalent and institute exfiltration detection. > > The big problem today is that "security" people in IT and security wannabee's > quote cracking numbers not based in the real world but mathematically based on quasi > "real" preconditions. They and some crazy guys who I know at Microsoft along with some > NIST guys are pushing 12 character minimums of upper, lower, numbers and specials, changed every 60 > days and no reuse for 2 years in business settings. They say this will make the corporate machines > safe. This is utter BS. And, in fact, makes corporate networks even more vulnerable due to the fact > that people can't remember all these password so they write them down or make them relatively > easy thus increasing social engineering break-in opportunities. > > The best solution is to select a computationally hard password and then don't change it > unless you have to. I also recommend that you select another that is different and use it for all > 'net based logins with a extension concatenated for each service. > > This comment about "if they _have_ managed to crack the password changing it forces them > to crack it again, thus also limiting the time the account is compromised" is ridiculous. > First, I assume you really mean stealing rather than cracking for the reasons above. > Notwithstanding the fact that the site broken into should immediately lock down all accounts. Whats > to say that the bad guys brake-in right after you have changed your password and they are not > noticed. You are still at risk until you change it maybe 30, 60 90, 120 days later. So what is the > real good of changing password routinely? Nada! The probability that your change matches the > threat is miniscule. It just make people feel good. In fact ,if the bad guys broke in to a > financial system they wouldn't steal your password; they would institute immediate bank > transfers. Not only would they; they do constantly today. > > As for the "black helicopters", Carnivore was never finished by the FBI and is part > of fokelore. Its much easier to do packet replication at a router in an ISP and send it to disk for > offline analysis. This also has another effect of having evidence that can be used in a court of > law. > > Other "issues" to be addresses later. > > Tom tl;dr Thanks for the essay, however I'm not suggesting that there is actual benefit. I'm listing the said benefits of changing your passwords. Regards, -Josh ____________________________________ Joshua Kehn | Josh.Kehn@gmail.com http://joshuakehn.com

« previous php.general (#310367) next »