faqts : Computers : Programming : Languages : PHP

+ Search
Add Entry AlertManage Folder Edit Entry Add page to http://del.icio.us/
Did You Find This Entry Useful?

13 of 28 people (46%) answered Yes
Recently 7 of 10 people (70%) answered Yes


What is the essence of PHP encryption(using crypt(),mcrypt(),etc)if data on transit isn't safe?

Nov 27th, 2008 14:18
healthy man, dman, Anthony Boyd, Guest, http://www.ttnr.org

The apathetic response is, of course, "there is no point."  If you 
allowed a login over normal HTTP, then the password was transmitted 
free & clear over the wires, and anyone sniffing on those wires could 
see it.  Therefore, using PHP to encrypt the password before storing 
it in a database is silly, as the password has already been exposed.
However, there is another kind of response, which is that having one 
chink in the armor is no excuse to drop the armor and do battle 
naked.  A good PHP developer isn't going to let one mistake snowball 
into a whole bunch of mistakes.  Security isn't a guarantee, it's a 
deterrent.  If you make life difficult for the bad guys, they may go 
find easier prospects.  There are "grades" of difficulty you can 
accept, but the more secure you go, the less convenient it is.  For 
example, you can disallow any dictionary-based passwords on your 
system, to try to prevent brute-force dictionary attacks (someone runs 
a script to try every word in a dictionary as the password), but then 
it's harder for people to remember their passwords.  You make things 
too restrictive, and people find alternatives.  So developers and 
sysadmins are daily making decisions like this, trying to find a 
balance, knowing that some protection is a better deterrent than a 
wide-open system.
In addition, encryption is sometimes meant to protect from internal 
threats, such as disgruntled employees, BOFH, whatever.  Consider 
this.  An upset employee might copy a file on his way out the door.  
Or a DBA might get curious one day, and start perusing the database.  
Will they bother to set up a packet sniffer on the lines?  No, they 
don't have time or ability to pull off all that work undetected.  But 
an easy glance at the database?  Maybe.  So, like an arms race, you 
just escalate the defenses to make things more difficult for 
an "inside job."
Of course, protecting your data from internal threats while leaving 
the data open to attack from outsiders isn't exactly a "comprehensive" 
security policy, but it's clear that crypt and HTTPS are offering 
different kinds of protection, meant to address different sides of the 
same coin.