I was wondering how secure this would be. I don't have full code for it right now, but I'll try to explain it in words.
When a login button is clicked, using socket.io, the username and password will be sent to a Node Js server. Once the server receives the username and password, it will check a text file, to see if there is a username and password that matches. If there is, the user data will be sent back.
Is there any way that someone could access the text file without direct access to the server? Would this be secure in general?
this will surely get closed as not a coding question, but I will answer anyway.
So you intend to include the user name and password with every request? THats a lot of repeated authentication, use a JWT instead. Use a well known library for auth (like auth0). If you want to make your own mAke sure you send it over https.
Can somebody read the text file?
Well
do NOT store the password, stored a salted hash. This is not reversible so even if the text file gets stolen it doesnt have the password
in theory nobody cam get at the file. In practice there is a huge gap between theory and practice. All the password breaches you hear about are 'bad guys' accessing a file /db that nobody thought could be got at
There is a common requirement of storing user credentials securely (user id / user password) in the App and use them automatically next time the App starts, but I'm not being able to figure out how to do this without user interaction.
Using JSON Store I need a password to encrypt the information, so if I store user credentials in the JSON Store I will need to ask to the user for the password used to encrypt the information.
A solution I figure out is to store the user id in a JSON Store without encryption and the password in a JSON Store encrypted with the user id as password. May be this solution provide a bit more security than not to encrypt anything but I think is not a complete solution.
As explained in the comments this is a really bad idea.
Is there any solution to store user credentials securely and recover them without user interaction?
You can use the Keychain API on iOS. Android doesn't seem to have an equivalent API.
The most complete solution I figure out is to store the user id in a JSON Store without encryption and the password in a JSON Store encrypted with the user id as password. May be this solution provide a bit more security than not to encrypt anything but I think is not a complete solution.
I would strongly advise against doing that, if you store the encryption key (the user id) in plain text, then the attacker can simply use that to get to the password.
Update (Aug 27, 2014)
You should consider:
Hashing - You could hash values you want to protect. These are one-way functions, so you can't get the password back once you hash it. However, you can verify that the user provided the correct password. For example: First login you store( hash(password) ) then on next logins you compare if hash(password_provided) == stored_password_hash. If it matches, the user provided the same password. You should also use a salt.
You could give the user the ability set a pin using some library like ABPadLockScreen (you could probably find or implement something similar for Android too). You can then use the pin as the PBKDF2 input to generate an encryption key (JSONStore will do this for you when you pass the pin as the password). I would advise in favor of letting users only try a small amount of incorrect pin numbers, especially if the pin is only numeric and short, that way they can't easily guess the pin by trying various combinations. The idea here is that a pin will be easier to remember and type than their password.
FYI - There's a Stack Exchange site similar to StackOverflow but for security questions here.
I have an Android app that I allow users to have a password in and "lock" the app so their friends can't look inside without their password. It doesn't use a web service or anything, and the password is stored in a private file within the app. Problem is, the users like to forget their password, then email me asking me to do something about it. Right now I can't. So what I want to do is have something that creates, and consumes a random password. The user could email me, and I could give them some random key the app could recognize, and let them in so they can change their password.
It doesn't have to be anything super secure. Any help is appreciated.
I don't think its a good idea to implement a "backdoor" in your application. THis will create a very bad taste.
If i understood correctly, you want to "unlock" the application, not knowing if the user doing this is in some way authorized. I steal a device, send you an email and you take care i can see the data. Sounds bad...
All (good) safes i know rely on the user to take care of their keys. They want security and they are responsible.
EDIT
You can provide a "security question".
Anything else i tried to construct for an "autonomous" password reset raises sever security questions (what are the authentication/authorization mechanics)
EDIT
How far are you willing to go? Assuring the possession of something (like an SMS or mail account) may reduce the issues and give some impression of security. So you can intercept SMS or mail from a PREDEFINED (application settings) account with lets say the key word "unlock". If not set, this feature is disabled. SMS interception should no be that hard.
Why don't you just build password reset functionality in the app itself? If it's not using a web service, why do you or your server need to be involved at all?
If they don't remember their security passwords, for example, your server could store an md5 hash of their password to match up their mobile device with their record on your server so you can send them a key to reset the app.
Couple of thoughts:
Is there any sort of registration process? If so, at registration time you could randomly generate a second password that you don't tell the user but just keep on file for such contingencies. Or similarly, you could offer users a "password recovery" option -- click this button to generate a backdoor password.
You could have some algorithm that generates a password from the machine id of the device and that works as an alternate password. If you were a big organization with millions of copies of your app out there, or if the information in your app was super secret, this would be a super bad idea, as sooner or later hackers would figure out the algorithm and then they could break into any machine they wanted to. But if you're a small target, it's likely no one would work hard enough to crack it.
Do you necessarily know anything about your users? Like could you generate a password from their credit card number or their address or some such? Of course this makes you vulnerable to any hacker who could discover whatever information about a potential target.
Anything like this you do you are going to create a big potential security hole: What if someone steals someone else's device, then emails you and says they lost their password? How do you know it's the rightful owner of the data? If anybody can call or email and say, Hey, I lost my password, please let me in the back door, then you have no security any more.
I am trying to store a username and password to hash against for future offline logging in. What is the best way to do this in objective c?
I will need the password to be stored securely.
Well, you can either create a file and store the information there, or you can put it in NSUserDefaults. I guess it depends somewhat on what your program does and how you really want it to work. If you're trying to store sensitive information (like plaintext passwords), you can use Keychain Services.
Use Keychain services (or keychain services for iPhone)
What algorithm should I use for encrypting and embedding a password for an application?
It obviously is not bullet proof, but it should be good enough to thwart someone scanning the database with a hex editor, or make it hard for someone who has the skills to use a debugger to trace the code to work out, either by scanning for the encrypted password, or using a debugger to run through the decryption code.
Object Pascal would be nice.
Major Edit
I think I did not explain myself well enough. The password needs to be decrypted back into its original form and applied. The application itself uses a local SQL database and a local webserver, and the password is fixed and can't be changed by the end users. It is to ensure that changes to be made only from within the app itself. The user passwords are only to allow access to the app itself, rather than the database
/vfclists
If you want an easy solution just stick with a good hashing algorithm like MD5 and store just the hash inside your application. Then whenever the user inserts the password you will calculate the hash of the password and check if it's equal to the one stored.
Of course this approach is a simple solution that doesn't allow you to retrieve the password if it's lost but it should work quite fine if you just need some protection..
EDIT: I mentioned MD5 that was fair good but not anymore, of course you can choose any other stronger function like SHA-2 (512/384) that is more robust. I just wanted to explain an approach more than using a specific hashing algorithm.
SHA should be ok for you, best with salt.
I don't know Object Pascal very well, but probably this will help you:
http://sourceforge.net/projects/op-crypt/
When an application has to do password checking only, it is best to save a hash. An hash can not be decrypted, but it can be checked whether the password the user enters has the same hash.
If you want to save the password so that it can be recovered, it is best to encrypt it first, using some crypto library.
I would suggest SHA1, its one way encryption, i've used it before and by far no one has decrypted it!
If you need more information on sha1 visit http://en.wikipedia.org/wiki/Secure_Hash_Algorithm and http://www.openssl.org/docs/crypto/sha.html.
PS: If you're using php you can simply encrypt with SHA1 using the sha1(); function!
I suspect that what you're aiming for is not storing passwords in the application, but trying to prevent the application itself from being run without the password, as a form of DRM. If that's the case, and you're looking to stymie people with debuggers, I think you're well into the realm of needing either a hardware dongle, or a network-based lock. Off the top of my head, I know SafeNet carry products that do this (and I've had some exposure to them in the past, they seem decent), but I don't know how well they compare to the rest of the market.
If you want as much real security as is possible in the scenario you're describing, you should require that when the system is installed an "administrator" enters the database password and his own administrator password; the application should then store a salted hash of the administrator's password, and it should store the database password encrypted with a differently-salted hash of the administrator's password. The database password (or information sufficient to reconstruct it) will be kept in memory while the program is running, but absent the administrator password there would be no way to retrieve when the program isn't running, even with full knowledge of the system.
If it's necessary to allow multiple users to access the database, an "add user" button could allow the addition of a user account. When the user types his password, use it to store hashed/encrypted data as with the administrator.
Any user with a debugger would be able to leverage his knowledge of a valid user account and password into knowledge of the database password, but someone who didn't have knowledge of a valid account password wouldn't be able to do anything.
If I am interpreting your question right, then you want to basically distribute your application to users, allow them to run it, and have the application update your database. At the same time, you want to prevent that person from being able to log in to the database and use it themselves directly.
If your program can be decompiled (like java, but I don't know about other languages like C, C++), then the person who has your application will be able to see the source code. Once they have that, there will most certainly be some way they can discover the user name and password. Even if your source code has stored the password using a reversible encryption algorithm, the person who holds your source code will be able to write similar code as yours to reverse the encryption and discover the password.
Even if your application cannot be decompiled, the user may be able to capture the network packets it sends to the database and determine the password from that. I don't know if you can communicate with the database over SSL.
Instead, I believe you need to split your application into client and server applications. You can write a restful web application, or use a messaging service (like JMS for example), and write a client application that uses it.
In that case, you may or may not want to have user accounts that are managed by your server side application. Let me be clear here, I am not talking about database accounts, but accounts that your application manages, and whose details happen to be stored in the database. If you do create user accounts, you can follow the pattern in my original answer shown below.
============== Hashing Approach, my original answer ============
As others have already mentioned, it's best to add salt to the password and use a digest algorithm before you store the password in your database. However, I think a little more detail is in order.
Using SHA1 or SHA2 with a salt value may be pretty strong, but there are even stronger methods. I highly recommend that you read this section of the spring security manual. I don't think you are using spring or java, but that section covers the concepts involved very well. Allow me to paraphrase:
Use at least an 8 byte salt value, up to 16 bytes would be great. The salt value should be different for every account, if it is the same then a cracker will only need to produce one rainbow table! It should be randomly generated. The documentation doesn't say this, but I also recommend using a secure random number generator, don't use a random number seed that produces a consistent sequence of numbers.
You should hash the password multiple times because it will cause brute force password hacking attempts to take increasingly more time. Indeed, you may want a slow password encoding algorithm instead of a fast one.
Store the raw salt value in the database along with the password, you can even store it in the same field/column. This is required so passwords can be verified in the future.
The BCryptPasswordEncoder is a good example of this.
===============
One alternative approach that may or may not solve your problem is to create a database account that has limited privileges. For example, you could create a database account that can only select, update, insert, and delete on specific tables in your database. You may not find this acceptable, because you may not want to let people do those operations directly, while you may want to let the application do those operations. It depends on your specific situation.