4 ms·

This is one of my pet peeves. I can implement some basic authentication in something like 25 lines of code. AuthLogic: 2500 LOC. Devise: 2200 LOC. Clearance: 69

This is one of my pet peeves. I can implement some basic authentication in something like 25 lines of code. AuthLogic: 2500 LOC. Devise: 2200 LOC. Clearance: 690. And yet, both times I tried to use AuthLogic, it actually didn't work for my case–login and password in different tables–without some weird hacks, at least not back then. My own custom authentication code can do that by simply modifying an existing LOC, and I know what is going on. There's no way I am going to ever feel comfortable with e.g. AuthLogic's code, simple because I can't justify spending time getting comfortable with it, when I can write it myself in 15 minutes. It's the same issue I have with RSpec, actually. Too much code.

tptacek 16y ago
I actually kind of agree. Rails Auth isn't a hard problem. As long as you're not rolling your own password hash and you're not rolling your own session store, I'm comfortable saying "authentication code in Rails is just glue; do the simplest thing that can work". Now, authorization is a radically different story; unfortunately, though, there's no good Rails solution for getting "off-the-shelf" access control and permissioning, so you may be kind of stuck anyways. (Pet peeve of mine? Mixing up authorization and authentication.)
- epochwolf 16y ago
  > (Pet peeve of mine? Mixing up authorization and authentication.) For anyone that's confused: Authentication: Is the user who they are they are? Authorization: Is the user allowed to do this?
- euroclydon 16y ago
  I hear, "Don't roll your own session store" frequently, but I wonder, is there any way to not roll your own session store when you are creating a single-sign-on application across multiple server technologies (PHP, ASP.NET, Rails)?
  - tptacek 16y ago
    Nope. Be really, really careful. This is one of the top game-over problems that happens to smart dev teams.
    - ichverstehe 16y ago
      Can you elaborate on that?
      - euroclydon 16y ago
        Go back and read through Thomas's comments here regarding attacks on encrypted passwords. Try this: http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.ycombinator.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.yc... Find all his warnings, and don't make any of the mistakes he mentions, and I'll bet you will be fine.
        tptacek 16y ago
        I'd be more worried that: * The session token you come up with will be insecure, like PHP's have been as recently as (I think?) this year * That you'll end up reinventing session fixation vulnerabilities * That you'll screw up session timeouts and logouts and succumb to "permanent" session hijacking flaws * That you'll try to encode encrypted information into the session cookie itself, rather than just an opaque random token, and open that whole kettle of worms.

tptacek 16y ago

I actually kind of agree. Rails Auth isn't a hard problem. As long as you're not rolling your own password hash and you're not rolling your own session store, I'm comfortable saying "authentication code in Rails is just glue; do the simplest thing that can work". Now, authorization is a radically different story; unfortunately, though, there's no good Rails solution for getting "off-the-shelf" access control and permissioning, so you may be kind of stuck anyways. (Pet peeve of mine? Mixing up authorization and authentication.)

epochwolf 16y ago
> (Pet peeve of mine? Mixing up authorization and authentication.) For anyone that's confused: Authentication: Is the user who they are they are? Authorization: Is the user allowed to do this?
euroclydon 16y ago
I hear, "Don't roll your own session store" frequently, but I wonder, is there any way to not roll your own session store when you are creating a single-sign-on application across multiple server technologies (PHP, ASP.NET, Rails)?
- tptacek 16y ago
  Nope. Be really, really careful. This is one of the top game-over problems that happens to smart dev teams.
  - ichverstehe 16y ago
    Can you elaborate on that?
    - euroclydon 16y ago
      Go back and read through Thomas's comments here regarding attacks on encrypted passwords. Try this: http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.ycombinator.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.yc... Find all his warnings, and don't make any of the mistakes he mentions, and I'll bet you will be fine.
      - tptacek 16y ago
        I'd be more worried that: * The session token you come up with will be insecure, like PHP's have been as recently as (I think?) this year * That you'll end up reinventing session fixation vulnerabilities * That you'll screw up session timeouts and logouts and succumb to "permanent" session hijacking flaws * That you'll try to encode encrypted information into the session cookie itself, rather than just an opaque random token, and open that whole kettle of worms.