• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Handling username and passwords in windows app

JumBie

Golden Member
I am creating a windows desktop app that will have the user create a user name and password. How can I store this securely? I understand I would want to store it on a separate server, but Is there any program or service out there that I can just integrate into my program for it to handle user names and passwords?

For example, I create the program to accept/create usernames and passwords but another server or service handles the security and storing of this, and all my program does is access it.
 
Just to throw something out there, what about SQLite. I would presume encrypting/hashing the contents of the password field would be easy enough.
 
Look into openID and OAuth. Both of which are the more standard way to do it so you can avoid the problems of leaking passwords. Otherwise you need to make sure you get your hashed password setup correct, and that is not as simple as it sounds.
 
Otherwise you need to make sure you get your hashed password setup correct, and that is not as simple as it sounds.

It's fairly easy. There as tons of good security documentations and literature available(dont know need a degree in cryptography or math). I would never understand how the hell huge companies with "security experts" can go about storing passwords in plain text or simple hashes that aren't even salted.
 
It's fairly easy. There as tons of good security documentations and literature available(dont know need a degree in cryptography or math). I would never understand how the hell huge companies with "security experts" can go about storing passwords in plain text or simple hashes that aren't even salted.

Depending on the actual security needs, a simple salted and hashed password stored in a DB might be decent enough for his needs.
 
It's fairly easy. There as tons of good security documentations and literature available(dont know need a degree in cryptography or math). I would never understand how the hell huge companies with "security experts" can go about storing passwords in plain text or simple hashes that aren't even salted.

And this is why you see companies getting 'hacked' all the time.

Security is NOT fairly easy. For as much 'good' documentation you can find there is 10x the amount of terrible documentation that exists.
 
And this is why you see companies getting 'hacked' all the time.

Security is NOT fairly easy. For as much 'good' documentation you can find there is 10x the amount of terrible documentation that exists.
No one means that it's physically easy as in: "It takes 60 minutes". But that following tried and true guidelines for implementation is usually a good start and makes it easier to stay within acceptable boundaries.

Most major companies that get hacked and where the fallout is big is usually because they actually neglected to follow standard design principles.

Two examples
Adobe: Used encryption with a single key for all passwords
Sony: No form of protection for PSN passwords

Commonsense is usually the best place to start, at least with storage and transfer of sensitive data. Proper implementation really only requires more time not necessarily more complexity.
 
No one means that it's physically easy as in: "It takes 60 minutes". But that following tried and true guidelines for implementation is usually a good start and makes it easier to stay within acceptable boundaries.

Most major companies that get hacked and where the fallout is big is usually because they actually neglected to follow standard design principles.

Two examples
Adobe: Used encryption with a single key for all passwords
Sony: No form of protection for PSN passwords

Commonsense is usually the best place to start, at least with storage and transfer of sensitive data. Proper implementation really only requires more time not necessarily more complexity.

Most of the major hacks come from SQL Injections. I am fairly sure "Sanitize your inputs" is in the top 3 of best practices for security.
 
Most of the major hacks come from SQL Injections. I am fairly sure "Sanitize your inputs" is in the top 3 of best practices for security.

Yep, and that's only part of the picture.

There is no such thing as perfect security, it's always a moving target.

Having good practices for storing passwords is only one part of the game.

That's why, in my opinion, if you are at the point of writing your own authentication scheme all the way down to encrypting your passwords and you are asking for help on how to do it on a public forum, you really should take a step back and come up with a better plan.

There are some good suggestions in here so far that leverage tested and well known implementations, but rolling your own authentication scheme because it is 'fairly easy' is just a terrible idea.
 
The thing is, we don't know the scope of what the OP's program is for. It could be for something for internal use among his family, or team at work, or whatever and never be public facing. So, a lot of just using best practices works due to obscurity. Hopefully, OP is asking how to set up security for his bank's outward facing website.

Most of these large hacks we see are from vulnerabilities that should never exist in enterprise. If your company gets hacked via SQL injection or your storing plaintext passwords in your database, you deserve to be shut down.
 
Most of the major hacks come from SQL Injections. I am fairly sure "Sanitize your inputs" is in the top 3 of best practices for security.
That falls under "Proper implementation" and sanitizing input is also a best practice/guidelines which i also mentioned. No point mincing words.
 
That falls under "Proper implementation" and sanitizing input is also a best practice/guidelines which i also mentioned. No point mincing words.

I was agreeing with you. I only was using that as an example of how the major hacks were because proper implementation wasn't followed. His idea that because major companies were hacked is a sign that security is hard doesn't work, because those major companies weren't following even the most basic of security guidelines.
 
Hey guys, sorry for the late reply. I scrapped the desktop application idea, and have been working on a strictly HTML5 based website. Now now I have my template all setup and am working on employing a PHP script that will allow users to create an account and log in. This information I am sure I can store on MYSQL database, however within this log in system I want to allow the user to store their credit card or Paypal information so that they can make reoccurring payments without having to type all their information in again. I am completely aware that this information should not be stored on MYSQL and I will not do that. However, that leaves me confused, what do I do now? How can I integrate something like this within the user account system? I am doing some research on this right now but I am not finding much specific information.

EDIT: Never mind screw it I'll just use Paypal or Amazon payments to handle all of this, no need for me to go through the legal issues involved and all the headaches.
 
Last edited:
Back
Top