Jump to content

Handling passwords in a database


pizzaguy
 Share

Recommended Posts

I'm trying to create a website that integrates with the API of another website, so I need to be able to store the users' passwords for this other site. Naturally, I want to try to protect them as effectively as possible, but they need to be able to be decrypted so that the regular password can be sent to the other website. What's the best way to handle this situation? I could encrypt them using something like AES encryption—Actually, does PHP have support for high end encryption like AES, Serpent or Twofish?—but that would mean anyone with access to the database of encrypted values, and the means to figure out the encryption technique (viewing the PHP files), could discover the passwords. One method I thought of would be to base the encryption on the plain-text password for my website (as the encryption key) upon log-in, since that password would be encoded with one-way encryption like md5, and then store the plain-text password in a session. My only problem here is that I have no idea how secure sessions really are; since they're stored on the server, are they secure, or could someone (on either client or server side) easily view them?Anyone have any ideas of the most effective technique for this situation?

Edited by Pizzaguy
Link to comment
Share on other sites

I'm trying to create a website that integrates with the API of another website, so I need to be able to store the users' passwords for this other site. Naturally, I want to try to protect them as effectively as possible, but they need to be able to be decrypted so that the regular password can be sent to the other website. What's the best way to handle this situation? I could encrypt them using something like AES encryption—Actually, does PHP have support for high end encryption like AES, Serpent or Twofish?—but that would mean anyone with access to the database of encrypted values, and the means to figure out the encryption technique (viewing the PHP files), could discover the passwords. One method I thought of would be to base the encryption on the plain-text password for my website (as the encryption key) upon log-in, since that password would be encoded with one-way encryption like md5, and then store the plain-text password in a session. My only problem here is that I have no idea how secure sessions really are; since they're stored on the server, are they secure, or could someone (on either client or server side) easily view them?Anyone have any ideas of the most effective technique for this situation?
What page don't sound what secure.. sending out the users passwords to anyone who wishes to use their API. I have hard time to believe you get the users password otherwise you found a great security hole.I would guess you would get a user id number from there page, and information about the user. BUT NOT PASSWORD, NEVER PASSWORDS!Is there a documentation on this API on how it's designed to be used or what page are you trying to extend? It's hard to help you without what information.
Link to comment
Share on other sites

What page don't sound what secure.. sending out the users passwords to anyone who wishes to use their API. I have hard time to believe you get the users password otherwise you found a great security hole.I would guess you would get a user id number from there page, and information about the user. BUT NOT PASSWORD, NEVER PASSWORDS!Is there a documentation on this API on how it's designed to be used or what page are you trying to extend? It's hard to help you without what information.
I'm not sure I understand you, but I think you're misinterpreting me. If I understand you, I think you believe I'm saying that site B is giving me the user's password. The Other website (which I'll now call "Website B"), has the API. I want users on my site (Website A), to provide their password for Site B, so that site A can login to B's API and retrieve the desired information for use on site A. An example of the API is a call with information that includes "email", "password", and "information" attributes, in which the user logs in with the email and password, and the "information" is retrieved for use in my site.
Link to comment
Share on other sites

If you can afford it, separate the important data onto two separate machines in two separate facilities, so as to prevent physical and social cracking both. The chances of a cracker accessing one machine are high, but not impossible. The chances of the same cracker accessing both machines are astronomical, as long as there is no clear indication on either machine that the two are associated.Heck, you might even need a third machine to make the association. I haven't done it, but I think it could work. (A high-stakes security expert does not post on a board like this.)If this is really important stuff, that's what you'd do, and the money wouldn't matter, because if it's important, you already have the money. And seriously, three hosts? $300 bucks annually.If you're talking about downloading game stats or something, I really wouldn't make a fuss. Plenty of sites store passwords in plain text. You know this because they send you your password in plain text when you answer the security question about your pet's name. They do it when the stakes are not high, like commenting privileges on a blog.

Link to comment
Share on other sites

Well, I'm certainly not going to be putting huge sums of money on the line; all I intend to do is basically include information from a blogging website. So, it's not critical information, but I certainly don't want people to feel that their accounts are vulnerable. Presently, I only really have the means for a single server set up; I would be very happy if the site actually got to the point were multiple servers were necessary.

Link to comment
Share on other sites

Well, first of all, their read stream is public. There's no authentication needed to read anybody's stuff. That's no different then Twitter, or Youtube. Some API's only require an appId in order to get public access. Only private read stream and write access requires authentication. Facebook and myspace on the other hand require OAuth. So those are the ends of the spectrums to consider. personally, it doesn't seem too big of a deal to have to guard these passwords, even if all you do is just make it known in the signup process that your application saves their username and password in order to make requests on their behalf, and maybe give an option to deactivate or opt out in the future.

Edited by thescientist
Link to comment
Share on other sites

ok. but aren't we just talking about how to best store people's passwords? I was just pointing out that some big name websites just give out access without even authenticating. You are at least authenticating, but just tell people that you're saving their information, just for the sake of full disclosure. If somebody was trying to impersonate someone else, your app would still require them to authenticate, and honestly, your app will never know if they are even the actual owner of the account. So if they've already got that other person's username and password, what could you be expected to do about it? edit: as for people getting their accounts hijacked, what's to stop people from reading someone eles Twitter or Youtube account? I could do that with anyone if I wanted to. Typically, as far as 3rd party API's go if it's free to see (on the web) it's free to read (from that third party API).

Edited by thescientist
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...