3 ms·

Whilst I think that the Padrino framework is an excellent effort, I would like to remind everyone (chiefly the project organisers) that as things stand, the fra

by tekacs 14y ago

Whilst I think that the Padrino framework is an excellent effort, I would like to remind everyone (chiefly the project organisers) that as things stand, the framework has no meaningful notion of security for the admin interface. I flagged this up about two years ago, now, but stopped using the framework shortly thereafter and never pushed any fixes of my own. The complete lack of meaningful authentication appears to still be there all this time later. For reference, see: https://github.com/padrino/padrino-framework/issues/384 https://github.com/padrino/padrino-framework/issues/384 and http://tkcs.in/Nlrc http://tkcs.in/Nlrc Though I would hope that Padrino admin isn't in fact being used in production by anybody who hasn't read the source, a quick search at the time showed otherwise.

tekacs 14y ago
And please, do correct me if I'm wrong (if this has in any way been fixed since).
DAddYE 14y ago
Tekacs: 1) We use bcrypt: https://github.com/padrino/padrino-framework/blob/master/padrino-admin/lib/padrino-admin/generators/templates/account/activerecord.rb.tt#L32 https://github.com/padrino/padrino-framework/blob/master/pad... 2) Auth is an API we generate that for YOU, but you can change the code generated to fit your needs.
- tekacs 14y ago
  Huzzah, with regards to the point of BCrypt (presumably the second link goes to currently dead, but left-in-the-codebase helpers). On the other hand, the first (original) point (the GitHub issue) still stands to this day - it would make sense to either improve the default implementation of Auth to be usable (as per most every sane framework out there) or to provide a warning somewhere (at least on the Padrino guide for admin & auth?) would it not?
- DAddYE 14y ago
  3) session_id is different from session_secret (generated also for you with SecureRandom, but also there you can change it)
  - tekacs 14y ago
    I would be very glad to hear that a session_secret is being used to encrypt session cookies (which would prevent the (working-at-the-time) 'attack' I posted in the abovementioned issue). I can't tell at a glance whether this change was made after the issue and if the problem is now overcome, but I'm glad to hear that security is at least on your minds! Just switching to BCrypt from the old DES'd passwords is a wonderful step! Best of luck and thanks for the great project!
    - DAddYE 14y ago
      Thanks! BTW, I'm far to be that is 'secure' nothing is 'secure', but we are putting a lot of efforts in that way, crf tokens, rack-protection and so on ... so jump in the community and help us to improve security aspects. Thanks for all!
    - Argorak 14y ago
      We're using standard Rack and Sinatra when it comes to sessions. So clearly: yes, always has.
- DAddYE 14y ago
  Tekacs, you are right, current auth is the most simple thing we have in mind. For sure can be better and so we planned to follow more an API standard so to be interchangeable with others auth systems. That helper is 'dead'. Will be removed before 1.0. If you have some others suggestions or you think there is something insecure, please share your thoughts. In this release we did a lot of stuff to improve that area, so you are welcome!

by tekacs 14y ago

tekacs 14y ago

And please, do correct me if I'm wrong (if this has in any way been fixed since).

DAddYE 14y ago

Tekacs: 1) We use bcrypt: https://github.com/padrino/padrino-framework/blob/master/padrino-admin/lib/padrino-admin/generators/templates/account/activerecord.rb.tt#L32 https://github.com/padrino/padrino-framework/blob/master/pad... 2) Auth is an API we generate that for YOU, but you can change the code generated to fit your needs.

tekacs 14y ago
Huzzah, with regards to the point of BCrypt (presumably the second link goes to currently dead, but left-in-the-codebase helpers). On the other hand, the first (original) point (the GitHub issue) still stands to this day - it would make sense to either improve the default implementation of Auth to be usable (as per most every sane framework out there) or to provide a warning somewhere (at least on the Padrino guide for admin & auth?) would it not?
DAddYE 14y ago
3) session_id is different from session_secret (generated also for you with SecureRandom, but also there you can change it)
- tekacs 14y ago
  I would be very glad to hear that a session_secret is being used to encrypt session cookies (which would prevent the (working-at-the-time) 'attack' I posted in the abovementioned issue). I can't tell at a glance whether this change was made after the issue and if the problem is now overcome, but I'm glad to hear that security is at least on your minds! Just switching to BCrypt from the old DES'd passwords is a wonderful step! Best of luck and thanks for the great project!
  - DAddYE 14y ago
    Thanks! BTW, I'm far to be that is 'secure' nothing is 'secure', but we are putting a lot of efforts in that way, crf tokens, rack-protection and so on ... so jump in the community and help us to improve security aspects. Thanks for all!
  - Argorak 14y ago
    We're using standard Rack and Sinatra when it comes to sessions. So clearly: yes, always has.
DAddYE 14y ago
Tekacs, you are right, current auth is the most simple thing we have in mind. For sure can be better and so we planned to follow more an API standard so to be interchangeable with others auth systems. That helper is 'dead'. Will be removed before 1.0. If you have some others suggestions or you think there is something insecure, please share your thoughts. In this release we did a lot of stuff to improve that area, so you are welcome!