3 ms·

I fail to see how the second example is more secure due to the abstraction. Simply adding a salt to the MD5 call would have around the same effect (probably tha

by ErrantX 17y ago

I fail to see how the second example is more secure due to the abstraction. Simply adding a salt to the MD5 call would have around the same effect (probably that's even what Authen::Passphrase does...). So is this a rant about abstraction or security? It is possible to make the original example safer without using abstraction. But the abstraction is important to make the applogic neater... I feel like the author is making 2 separate points at the same time - and confusing them slightly.

KrisJordan 17y ago
The third conflated point is a rant of Perl over PHP. "His language convinced him to do it wrong, and now he is pretty much stuck. And that's bad." PHP doesn't convince you to roll-your-own over use-someone-else's. The author could have just as looked to use PEAR as you looked to use CPAN. http://pear.php.net/packages.php?catpid=1&catname=Authentication&php=all http://pear.php.net/packages.php?catpid=1&catname=Authen... http://pear.php.net/manual/en/package.authentication.auth-http.auth-http.example.php http://pear.php.net/manual/en/package.authentication.auth-ht...
- jrockway 17y ago
  There is a culture of not using libraries in PHP, because the built-in functionality is "good enough". People make the same mistakes again and again and again. (Just today there was a Rails "best practices" article saying how to roll your own salted digest authentication from scratch. WTF!?) And anyway, I don't see a bcrypt implementation there. People will do what's easy; if it's as easy to do the (significantly more secure) bcrypt, they will. If it's easiest to do an unsalted MD5 digest, they will. Someone certainly could write a library exactly like Authen::Passphrase for PHP or Ruby or whatever; but they haven't, so people do it wrong. They have gotten used to not having libraries, so they don't even look. (They search for blogs instead, and cut-n-paste years-old code. The culture practically insists on it.)
  - mattyb 17y ago
    PHP 5.3 contains a native bcrypt implementation. http://php.net/manual/en/function.crypt.php http://php.net/manual/en/function.crypt.php
    - jrockway 17y ago
      Excellent. Still a horrible API, though. (How do you control which algorithm will be used? How do you model "this password is the lack of a password"? Etc., etc.)
      - mattyb 17y ago
        The encryption type is triggered by the salt argument. So if you want Blowfish, you'll need to supply a sixteen-character salt. What exactly do you mean by "this password is the lack of a password"? Edit: is http://search.cpan.org/~zefram/Authen-Passphrase-0.006/lib/Authen/Passphrase/RejectAll.pm http://search.cpan.org/~zefram/Authen-Passphrase-0.006/lib/A... what you're talking about?
japherwocky 17y ago
I think the author is just trying for some publicity by rehashing popular YC memes. His post about PHP and security is flaming a line of example code extracted from an article on an introduction to Javascript.
- jrockway 17y ago
  Wrong. My blog does not need any readers. There are no ads, and everyone that needs to know about me knows about me. I wrote this because I think the ideas are important to share -- abstraction is critical to having secure and maintainable code, and your language choice affects how you think about problems. I did see the Javascript article here, of course.

by ErrantX 17y ago

KrisJordan 17y ago

The third conflated point is a rant of Perl over PHP. "His language convinced him to do it wrong, and now he is pretty much stuck. And that's bad." PHP doesn't convince you to roll-your-own over use-someone-else's. The author could have just as looked to use PEAR as you looked to use CPAN. http://pear.php.net/packages.php?catpid=1&catname=Authentication&php=all http://pear.php.net/packages.php?catpid=1&catname=Authen... http://pear.php.net/manual/en/package.authentication.auth-http.auth-http.example.php http://pear.php.net/manual/en/package.authentication.auth-ht...

jrockway 17y ago
There is a culture of not using libraries in PHP, because the built-in functionality is "good enough". People make the same mistakes again and again and again. (Just today there was a Rails "best practices" article saying how to roll your own salted digest authentication from scratch. WTF!?) And anyway, I don't see a bcrypt implementation there. People will do what's easy; if it's as easy to do the (significantly more secure) bcrypt, they will. If it's easiest to do an unsalted MD5 digest, they will. Someone certainly could write a library exactly like Authen::Passphrase for PHP or Ruby or whatever; but they haven't, so people do it wrong. They have gotten used to not having libraries, so they don't even look. (They search for blogs instead, and cut-n-paste years-old code. The culture practically insists on it.)
- mattyb 17y ago
  PHP 5.3 contains a native bcrypt implementation. http://php.net/manual/en/function.crypt.php http://php.net/manual/en/function.crypt.php
  - jrockway 17y ago
    Excellent. Still a horrible API, though. (How do you control which algorithm will be used? How do you model "this password is the lack of a password"? Etc., etc.)
    - mattyb 17y ago
      The encryption type is triggered by the salt argument. So if you want Blowfish, you'll need to supply a sixteen-character salt. What exactly do you mean by "this password is the lack of a password"? Edit: is http://search.cpan.org/~zefram/Authen-Passphrase-0.006/lib/Authen/Passphrase/RejectAll.pm http://search.cpan.org/~zefram/Authen-Passphrase-0.006/lib/A... what you're talking about?

japherwocky 17y ago

I think the author is just trying for some publicity by rehashing popular YC memes. His post about PHP and security is flaming a line of example code extracted from an article on an introduction to Javascript.

jrockway 17y ago
Wrong. My blog does not need any readers. There are no ads, and everyone that needs to know about me knows about me. I wrote this because I think the ideas are important to share -- abstraction is critical to having secure and maintainable code, and your language choice affects how you think about problems. I did see the Javascript article here, of course.