(12-23-2015, 04:09 PM)Maverick Wrote: (12-23-2015, 12:38 PM)skunkbad Wrote: There are some pretty major authentication issues. To your credit, you've only said that this is "basic authentication". It might be more helpful to provide a more robust authentication. Yes, it's nice to give a newbie something to start with, but you don't want them to have the impression that websites they make for themselves or other people are reasonably safe by using what you've provided.
Thanks for chiming in! Ironically, I did consider including Community Auth but felt it was just too much for this project, which is in fact why I went with a salted sha512 hash. I wouldn't necessarily use the words 'major issues'... since as you validated, this isn't intended for enterprise level applications. I'm am curious, though. What would you suggest to beef it up a little more? Crypt perhaps? I'm certainly open to any suggestions. Would you consider forking it and contributing?
First, I don't want to send your thread down a rabbit hole. I know what you've done is much more than authentication, and I can appreciate that. If you used or remembered the earlier version of Community Auth, you'd know that it too was sort of a starter application.
Using PHP's hash function may be fine for passwords. I think the default (because it was included with PHP as of PHP 5.3) is using BCRYPT for hashing. That is done with crypt, but also can be done with PHP 5.5's new password hashing function. That's not what I was most concerned with though.
1) You need to regenerate the session ID after somebody successfully logs in.
2) CI no longer has a config option to encrypt the session data, and whether using file based sessions or database based sessions, session data is sitting on the server as plain text. You should encrypt it.
3) You'll want to review how to properly set the encryption key, because copying binary data as a string is not the same as using binary data for an encryption key. When the encryption key is created, you'll use bin2hex to copy it, then use hex2bin in your config file. Also, because this is a distributed application, you shouldn't be providing an encryption key at all.
4) Although you want to have confidence that the session is tied to a specific user, you really should physically tie it to the user by storing the session ID in the user's database record. Update when the session ID is regenerated. Delete when they log out. You could alternatively do this in reverse, but only if using database based sessions.
5) There's no limitation on login attempts, so a bot can submit your login form endlessly looking for success.
6) There's no limitation on the username or password lengths. Imagine the computation time if somebody copy and pastes a few MB of data into the password field, and then submits your form 100 times per second.
These are just some of the things I thought about as I was skimming through your code, and by no means a thorough review.
Right now I'm not in a position to help out. I've got some pro bono work that is taking up all of my spare time. I'll let you know if that changes.
