Quote:
Originally Posted by JeremyMiller
I'd say the following:
1) Use database-based sessions. This makes hacking the session harder.
2) Require cookies. This will minimize session hacking.
3) Might want to just define session variables with the $_SESSION array since it's not 100% compatible with session_register-related functions.
4) Do not store passwords in plain-text form. Look at the hash() function. I usually use SHA512.
5) Protect against multiple attempts. There are 2 ways you can do this:
I) Only allow X number of attempts, or
II) For each failed attempt, make the user wait Y seconds between attempts. This doesn't protect you as much, but it slows down brute force scripts.
6) Do NOT use IP-based tracking. On large hosts, the IP can change from page to page which can be a real pain. I did this once and had quite a few AO-Hell members *****ing at me.
7) I suggest a username-based system instead of a login-based system where the username is used only for logging in. Why? Doing so makes it harder to guess 1/2 the equation (i.e. a hacker must guess both username and password instead of just password when provided the email [or it's easy to find]).
That should get you started. Good luck!
|
1) you talk about storing permanent session data in DB or something else?
2) cookies are a must, parsing the session UID by url is a no-f*-way
3) yeah I will do that if I use the build-in session system, for temporary stuff I need parsed along the pages.
4) SHA512 + salt + SHA512 + salt2 + SHA512 + salt3 + SHA512 + MD5 (yeah, this is closed source so I can make any combination I want.. and using MD5 in the end, confuses the hackers, 99% of them will think that the encryption is "pass + MD5".. and even If they do know that behind the MD5 there is a SHA512 hash... when are they gonna crack it? year 2150?
)
5) I'm still thinking about a way to make this as good as possible so that brute-force is slowed down and made hard, and DoS & DDoS are hard to pull off (for example they try to login into multiple accounts a few times and make allot of accounts frozen or temporary-locked)
6) I my country the dynamic-ip users get a new IP only when they reconnect. ip changing from page to page will not be allowed, if there are users that will need this, there will be special proxies available for them, but NOT those free-public ones as all of them will be banned.
7) I will be using username + password authentication, the username privacy will be the same as the passwords. so it's like 2 passwords to get in
now, I like you guys to take a look at the two systems below, and tell me possible exploits/holes and problems on both of them:
System 1:
------------------
> When the user registers, we generate a random 256 or 512 bit string, and store it in DB with his other info. These strings are unique for every username.
> When the user logs in with his username and password, we generate a custom UID based on:
--> The random string for that user (a.k.a the third password that nobody knows
)
--> His current IP-adress
--> The time he logged in
--> Some info about his browser
> The UID is encrypted like the passwords with custom combinations and salts, and is stored in DB.
> The custom random string, and the time the user logged in, are stored encrypted using a custom two-way encryption in a cookie, in clients browser
Also, the cookie names are "wtf" like "0xA1"
no-one has a single clue what-is-stored-where and how-its-scrambled
> On every page load, the info from the cookies is decrypted and combined with the rest of the stuff, the UID is re-generated and re-encrypted, and if it matches a UID in DB, the user is confirmed as logged in
> Every time the session is successfull, the last page visit time is stored with the UID, encrypted ofcourse.
> Exe service, checks for session UIDs that are not used for more than an hour, and deletes them. checks are done every minute.
> An option available to users, to make their sessions idle time last longer, at their own risk ofcourse.
--------------------------
System 2:
--------------------------
session_start
session_register()
session_isregistered()
session_unset()
session_destroy()
--------------------------
End
