Hi everyone, I'm new to fuelPHP, but not to PHP and web development. I would like to know how secure is auth. I wrote my own driver based on simpleauth, but some things in simpleauth are not clear to me...
For example remember me cookie contains user_id and no other info, and later if user_id is in cookie user will be logged in, doesn't that left leave oportunity to hacker to change cookie and log in as any user? Or is encryption secure enough in cookie to solve this?
Same thing is with standard login. Everything is written in session, and if driver for session is cookie username and loginhash is saved in cookie, which is ok, but if multiple_logins flag is true then it doesn't even checks for loginhash, doesn't that leave oportunity to hacker to change username and log in as any other valid user?
I would like to know how this things works in background and do you consider encrypting cookie good enough for this, or did I realize something wrong?
In short: very. It has been audited and tested by both a US and a Japanese security company.
The only issue found was a possibility for a time-based attack (a normal string compare varies slightly in processing time depending how many characters of the password are correct), which was then mitigated.
The remember-me feature is implemented using a custom session instance, so the cookie is protected the same way as the session is, including user-agent and IP checking (unless disabled in the config), and session id rotation.
Fuel's encryption uses AES, with an SHA256 hash. It uses random generated 128 bit key, IV and hmac values, unique per application.
The users password is hashed using PBKDF2, which is still considered "the safe choice" because it's very well tested and secure. Alternative is bcrypt or scrypt, which are promissing but less proven.
The biggest thread for your application isn't session hijacking. In the default setup the hacker would need to fake the users user agent string (i.e. need to know exactly what browser the user is using, and which detailed version), spoof the user's IP address, figure out how to get the result back since the IP was spoofed, and do this within 5 minutes, the session ID rotation time.
Instead, XSS attacks have more chance of succeeding, and don't require you to know anything of the user. So it's absolutely vital that you use CRSF protection on all your forms, and use a redirect after successful processing of the form (so the browsers back button can't be used anymore).
As I thought, encryption with a key is going on in cookie and that makes it safe, but I wasn't sure how safe. Anyway in my application I'm using file based sessions (it's less consuming and faster then SQL, and I don't have resources for memcache or reddis) that are outside of application and not reachable from web and in my auth driver I made session cookie saves only user id, while remember me works same as on simpleauth, but saves in cookie login_hash and user_id, while I turned off user_agent check and ip check (browsers get updated and that changes their UA string, we don't want to logoff user for that). I believe this should be good enough.
Why is everywhere on simpleauth manipulatingwith username instead of id?
Maybe because of encryption? it would be easier to break it with only numbers?
A per user salt is to create more randomness to protect against using rainbow tables.
The problem is, to be able to use that method of attack, the hacker needs access to the user table. And if that is the case, they have the salt too, since it's part of the same table.
The salt Auth uses is not in the database, and therefore not compromised when a hacker has access to your database.
> The salt Auth uses is not in the database, and therefore not compromised when a hacker has access to your database.
It is true, but a hacker could easily break the salt. And once he/she knows it, the salt is completely useless. All user passwords will be known with a rainbow table.
So it seems system-wide salt is not safer than per-password salt.
That may be true, but if you have a hacker that gets to that point, you're in serious shit anyway, since both your database and your filesystem are compromised.
At which time the hacker has - all usernames, with all password hashes, and all per-user salts - the full hashing algorithm used to create those hashes - the application wide salt used
So all the hacker has to brute-force is the user-entered part of the password, which with today's GPU power is peanuts.
If you want to be really secure, you need a per-user salt, a per-user pdkdf2 random iteration number, and you need to store the salt and the iteration number separate from the password hash. You also need to backup this data to different locations (as they might go for your backup storage instead).
You also need to filter your users pass-phrases on the likelyhood of dictionary attacks, and apply filter rules to common practices, like 1337 speak (P@ssw0rd), reverse strings or numbers at the end (kenjis001 or kenjis09!2014), etc.
Auth was not designed to protect a bank application, and changing this might have huge BC consequences. Some of these will be part of the Auth v2 implementation, like the per user salt and iteration.
Donate
