Accounts System?

[chaotixs]

I'm looking for a tutorial/helpful person to help me in setting up an account system for my website. I need one to help with the organization of my site. If anyone can help or needs more info about what I'm looking for, then please reply. Thanks.

 

[essellar]

It's not tremendously difficult or even all that complicated anymore. There is a lot of stuff built into the PHP language now that both simplifies things quite a bit and makes doing security right* easier than doing it wrong. But we're going to need a lot more information to be of much help.

Like -- okay, your users can log in. That part is twenty-ish simple lines of code that's hard to get wrong. So what? What does logging in mean in your case? Are you restricting access to parts of your site (members only)? Are there various levels of permissions (moderators, main content authors, editors/publishers, admins, that sort of thing)? Are there user profiles, "friends", and so forth? Should people be able to stay logged in over time? Partially logged in? ("I know who you claim to be, so here's your version of the site, but I won't trust you for important stuff this session until you give me your password again.")

No, we don't need the full spec. Just enough to give you something useful for you to build on, to get you pointed in the right direction. There's not much sense in handing you a tire and saying "you ought to be able to build a car out of that".
__________________________________
* Whenever you are dealing with logins involving usernames and passwords, especially if there's an email address involved, you have voluntarily become one of the Guardians of the Keys. It's not just about protecting your site. Most people use the same password (or couple of passwords) everywhere on the web, so you've just become responsible for protecting their Facebook page, PayPal and Amazon accounts, medical records... the whole kit and kaboodle. I hope that sounds scary enough. Because we don't have access to HTTPS on Free Hosting, we can't get everything right (individual users will still be vulnerable if someone can "sniff" their network traffic), but we can make it very, very hard for anybody to grab and crack all of our user info in one shot. By far, the vast majority of the tutorials, etc., out there on the web make life easy for crackers.

 

[chaotixs]

It's not tremendously difficult or even all that complicated anymore. There is a lot of stuff built into the PHP language now that both simplifies things quite a bit and makes doing security right* easier than doing it wrong. But we're going to need a lot more information to be of much help.

Like -- okay, your users can log in. That part is twenty-ish simple lines of code that's hard to get wrong. So what? What does logging in mean in your case? Are you restricting access to parts of your site (members only)? Are there various levels of permissions (moderators, main content authors, editors/publishers, admins, that sort of thing)? Are there user profiles, "friends", and so forth? Should people be able to stay logged in over time? Partially logged in? ("I know who you claim to be, so here's your version of the site, but I won't trust you for important stuff this session until you give me your password again.")

No, we don't need the full spec. Just enough to give you something useful for you to build on, to get you pointed in the right direction. There's not much sense in handing you a tire and saying "you ought to be able to build a car out of that".
__________________________________
* Whenever you are dealing with logins involving usernames and passwords, especially if there's an email address involved, you have voluntarily become one of the Guardians of the Keys. It's not just about protecting your site. Most people use the same password (or couple of passwords) everywhere on the web, so you've just become responsible for protecting their Facebook page, PayPal and Amazon accounts, medical records... the whole kit and kaboodle. I hope that sounds scary enough. Because we don't have access to HTTPS on Free Hosting, we can't get everything right (individual users will still be vulnerable if someone can "sniff" their network traffic), but we can make it very, very hard for anybody to grab and crack all of our user info in one shot. By far, the vast majority of the tutorials, etc., out there on the web make life easy for crackers.

This website is for my Tech Company, Chaotix Studios. I want an account system so users can keep track of contact tickets (maybe), I would also like to restrict access to a few pages for designated users (so permissions, yes.) I would like users to pick weather to remember their credentials/stay logged in too.
------------------------------------------------------------------------
I understand this, and I am ready for this.

 

[essellar]

That's still pretty vague. If you're not comfortable with divulging more detail here, then you can send me a private message, but I can't give you anything more than a generic overview with what you've given me so far. Like "use the password hashing API, create a user table in a database that stores the user name, password hash, a unique ID, and you'll need to store permissions, whatever 'permissions' means to you, somewhere", and that won't get you very far. Tire/car again.

 

[chaotixs]

That's still pretty vague. If you're not comfortable with divulging more detail here, then you can send me a private message, but I can't give you anything more than a generic overview with what you've given me so far. Like "use the password hashing API, create a user table in a database that stores the user name, password hash, a unique ID, and you'll need to store permissions, whatever 'permissions' means to you, somewhere", and that won't get you very far. Tire/car again.

I actually already have a table with fields for "id, username, password, bio, country, city" in my database. Permissions to me is giving access to certain things to only the people signed up. I'm actually not sure what "hashing" is, however.

 

[descalzo]

Hashing is using a function to "scramble" a string ( in your case a password ). It might turn the string "hello" into the string '5d41402abc4b2a76b9719d911017c592' (this is the string representation of a very large number in hex notation).

You should not store the passwords themselves. Otherwise, if someone gets access to your database, they have all the passwords. You store the hash of the passwords. Good hash functions make it impossible to get the original password from the stored hash value.

You store a hash of the password. When they try to log in, you take the password they give you, apply the hash function to it, and compare the result to the stored value.

Note that in this method, if someone forgets their password, you have to issue a new one, since you have not stored the original.

 

[leafypiggy]

This tutorial is a bit old and could probably use some updating, but it definitely is a good starting point. The community over there is also very helpful (though most of the people here can help, too)

http://webdevrefinery.com/forums/topic/3280-how-to-make-a-user-account-system/

 

[chaotixs]

This tutorial is a bit old and could probably use some updating, but it definitely is a good starting point. The community over there is also very helpful (though most of the people here can help, too)

http://webdevrefinery.com/forums/topic/3280-how-to-make-a-user-account-system/

Okay Awesome! Thanks!

Hashing is using a function to "scramble" a string ( in your case a password ). It might turn the string "hello" into the string '5d41402abc4b2a76b9719d911017c592' (this is the string representation of a very large number in hex notation).

You should not store the passwords themselves. Otherwise, if someone gets access to your database, they have all the passwords. You store the hash of the passwords. Good hash functions make it impossible to get the original password from the stored hash value.

You store a hash of the password. When they try to log in, you take the password they give you, apply the hash function to it, and compare the result to the stored value.

Note that in this method, if someone forgets their password, you have to issue a new one, since you have not stored the original.

Thanks for the explanation

 

[essellar]

Oh, my goodness could that use an update. Most of the system is good(ish), but the hashing and salting system is crackable at a rate of 5.6 billion hashes per second per machine. The new PHP password_hash()/password_verify()/password_get_info()/passwords_needs_rehash() API is tens of millions of times slower. To an end-user, that adds something like a tenth of a second to the log-in time. To a cracker, it makes the difference between 2 minutes to run through a set of possibilities and more than five years to run through the same set on the same hardware. That's a HUGE difference. And since "security" is really just another word for "delay", it's the kind of difference you need.

I don't know how many times I'll have to say this: YOUR SITE ISN'T IMPORTANT. You are securing the passwords that people use for banking, online purchases, confidential medical records, and a lot of other things that can ruin lives in minutes. There is no excuse for not doing it right anymore. And you may find yourself legally on the hook for other people's losses and damages.

 

[leafypiggy]

Oh, my goodness could that use an update. Most of the system is good(ish), but the hashing and salting system is crackable at a rate of 5.6 billion hashes per second per machine. The new PHP password_hash()/password_verify()/password_get_info()/passwords_needs_rehash() API is tens of millions of times slower. To an end-user, that adds something like a tenth of a second to the log-in time. To a cracker, it makes the difference between 2 minutes to run through a set of possibilities and more than five years to run through the same set on the same hardware. That's a HUGE difference. And since "security" is really just another word for "delay", it's the kind of difference you need.

I don't know how many times I'll have to say this: YOUR SITE ISN'T IMPORTANT. You are securing the passwords that people use for banking, online purchases, confidential medical records, and a lot of other things that can ruin lives in minutes. There is no excuse for not doing it right anymore. And you may find yourself legally on the hook for other people's losses and damages.

Oh no, definitely needs updating. The author of that particular post is busy. VERY busy. Just had another kid.