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
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