Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am building an web site which will allow users to aggregate the information stored in their online profiles ("data feeds") in one place.

I am wondering - what is the accepted (from a secureness point of view) way to store user name / password information in a my database?

Normally I would derive a salted-hash value from a password and would store this, but that obviously would not work in this case, as "data feeds" websites would need an actual password.

Storing the credentials it in a clear text is not an option, as it would be a huge security risk.

Not storing passwords in a database, asking users to type them in at the beginning of each session and then keeping them in a in-session memory does not seem like a viable option either, as it would be too much trouble for users to enter the same passwords many times again and again.

So far it seems that the only option is to encrypt passwords somehow, but I don't know what are the best design patters for such option.

Or perhaps there is way to deal with that problem, I haven't even considered ...

What would you recommend?

share|improve this question
    
what are you building your website in? –  Matt D Jun 20 '13 at 8:25
    
So basically you want your website to log in to other 3rd party websites get crawl data? Use the api that those 3rd party websites supply... –  Pieter B Jun 20 '13 at 9:05
    
@PieterB well, right ... but my question was not about using the 3rd party API, but how to store password which 3rd party API requires me to specify every time I make a call to a 3rd party API. Sorry if my question was not clear enough. Thank you. –  Mitten Jun 20 '13 at 9:20
5  
@Mitten "good" 3rd party apis don't work that way. Basically they let the user log in to their site giving your site permission to see data, without a need to use login details from the user to access their api. –  Pieter B Jun 20 '13 at 9:26
1  
Please do not encourage users to cross post questions across StackExchange sites. If you feel the question is posted in the wrong place then flag for a moderator and we will evaluate if it should be migrated or not. Thank you. –  maple_shaft Jun 20 '13 at 11:08
show 2 more comments

3 Answers 3

I think what you are looking for is what is known as SSO (Single Sign On):

Source: Wikipedia

a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, Single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.

The challenge of implementing single sign on is that you have to provide the implementation details for each unique type of authentication mechanism that all systems seem to use. Typically in an OOP application one would write Authentication Providers that know how to retrieve credentials and interface with outside system to where your system initiates and performs the "handshake", and then retains this trust for the remainder of the session.

A one-way hash like a salted digest won't work but you already know that. Strong two-way encryption is necessary, but you will need a key to perform this. Store the encrypted credentials in the database on a separate machine and lock down that servers firewall only exposing the required ports. Keep the key on the application server in an obfuscated non-obvious way. Keeping the key on a separate machine from the one that houses your database and encrypted credentials reduces the risk if a single machine becomes compromised. Any additional steps you can think of that will further obfuscate this will help with security.

EDIT: User Bart Van Ingen's suggestion about the key is the ideal situation, where the user provides the key when they log in, absolving you of the responsibility of maintaining the key/keys on your own system.

share|improve this answer
add comment

The general way is to use a one-way hash (plus salt, of course, and when I say "hash" here you should always mentally append "plus salt"), store the hash in the database. Then, when the user enters a password, you hash that too (using the same hashing function) and compare hashes.

However, I would not recommend that you build your own security system. The reason why is that security is hard, you don't know more about it than those that have already built security systems (and the fact that you're asking this question confirms it), and you shouldn't be thinking that you can do a better job than them.

Does your web server software provide a security system? Does your OS provide a security system? If so, and if you can, then use those instead of rolling your own. They're tried and tested, they've been worked on by security experts, they're designed to meet requirements of security certification, and no matter what you think, you can't write a better one yourself.

If this is not an option then look to use something like OpenID, Google, whatever. Just use something that's already been proven to work and that has the bugs (and not to mention security risks) already worked over.

share|improve this answer
    
even if I make my web site working with openid, or google id - the question still stands - how would I get it working with a 3rd party API which do require a username and a password? I don't see how ... do you? –  Mitten Jun 20 '13 at 9:40
add comment

As you are effectively providing a (limited) online password manager service, you could have a look at how the off-line password managers store the passwords for their users.

My napkin-design for such a feature would be to store the password in the database using a symmetric cryptographic encryption, where the key is either provided by the user or derived from a password that the user provides. This way, the user only has to provide a single password at the start of the session, regardless of the number of data feeds that get unlocked that way.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.