15

I'm developing an application. The user must enter his credentials which will be sent to the server. If the user opens the application a second time he shouldn't need to enter them again - credentials should be stored on user's machine. Also this data can be passed around. My app is cross-platform so I'm searching for a cross-platform solution. So step by step the algorithm should look like this:

  1. The user enters login and a password, and this data goes to the server. How can I securely pass it? Should I use a secure protocol like https or ssl?
  2. If the credentials are correct I need to save this data to the local machine. Should I use a local database file, a binary, or just a text file? Where to store this file? And I bet I need to encrypt this. Also I need to decrypt it later, but for decryption I need some additional data (some key, probably), right? Where to store this additional data?
  3. At some point I need to pass this information to another process. I already have tcp communication between processes established. Is this enough for passing? Should I pass it encrypted or decrypted.

Please correct me if my steps are wrong. This is a first time I'm dealing with security so I'm lacking knowledge.

  • You refer to app, server and another process as if they are all separate. Can you clarify differences between server and another process? Between app and another process? – user2338816 Jan 22 '15 at 0:58
10

HTTPS or a custom protocol using TLS for encryption is the correct way to securely communicate with a remote server, assuming you implement it correctly and exit if something isn't right with certificates (I've seen mobile apps that despite using HTTPS, accepted my self-signed certificate right away without even asking the user, making the whole "security" pointless).

Storing the credentials securely on the machine is a lot harder because if your app can decrypt them, so can malware running with the same privileges as your app - any protection would just be security by obscurity and won't stop a dedicated attacker, it may only protect against common "stealers" which are mainly designed to steal browser profiles (history, session cookies) or personal files (for possible identity theft) and won't steal the actual app binary so the attacker won't know how the saved credentials were encrypted, or even if he has the app's binary he may just not care because reverse-engineering is time consuming and requires experience (note that malware developers often aren't the ones who actually deploy them and collect/resell the stolen data).

You may derive a key from the hardware like pbkdf2(sha512(OSname+OSversion+CPUmodel+MACaddress)) and use that as a key to encrypt the credentials, which can be retrieved on the same machine but won't benefit an attacker if he only stole the encrypted credentials and the app's binary unless he has still access to the machine to go back and get that same value

There is no need to use encryption for inter-process communication on the same machine, if an attacker can intercept that communication he already has control of the machine (at the same privilege level that the app uses, if not higher) which means you can read what I said above about not being able to defend against that.

  • Thank you. Can you give an advise about protection for my case - maybe some links or terms, which algorithm is suitable? – nikitablack Jan 21 '15 at 12:31
  • encryption/decryption algorithm. And regarding to derive a key from the hardware - does that means that if the user change hardware the decryption stop to work? – nikitablack Jan 21 '15 at 12:35
  • 1
    @nikitablack use AES for encryption, and yes if the hardware changes the key is no longer the same and your app should fail gracefully and prompt the user for credentials again, to re-encrypt them again using the new key. – user42178 Jan 21 '15 at 12:39
  • 4
    For encryption and decryption with TLS, see my answer to Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?. For password hashing, see Thomas Pornin's canonical answer to How to securely hash passwords?. If you derive a key from the hardware, it is predictable, and it can be trivially found out - the example above can be trivially spoofed as well. Try searching for "Active Directory" or "LDAP" or "Kerberos" credential use instead. – Anti-weakpasswords Jan 21 '15 at 13:43
  • One solution would be to store the key on the server and the encrypted data on the app storage. Then, when the user goes to the app a second time, it sends the encrypted data to the server, the server decrypts it and checks if the data is correct or not. This is how I would do it. – Ismael Miguel Jan 21 '15 at 14:58
12

The user enters login and a password, and this data goes to the server. How can I securely pass it? Should I use a secure protocol like https or ssl?

Yes! You need to pass the data in a security way, using TLS for example.

If the credentials are correct I need to save this data to the local machine. Should I use a local database file, a binary, or just a text file? Where to store this file? And I bet I need to encrypt this. Also I need to decrypt it later, but for decryption I need some additional data (some key, probably), right? Where to store this additional data?

You can generate a key instead of the password, so for example, in the authentication the server returns a KEY (random bits) save that in a database with the ID of the user, and you store that KEY localy, but in the server you know who that belongs to. Then, in the second login, you send that key to the server, that checks if its valid (belongs to that user) and not expired.

At some point I need to pass this information to another process. I already have tcp communication between processes established. Is this enough for passing? Should I pass it encrypted or decrypted.

Again, you pass only the key. You can encrypt, but its realy hard to avoid all the types of attacks your system may suffer.

  • 1
    Thank you. Sorry, but I didn't understand why to use a KEY instead of a password. This KEY can be extracted by a third person the same way as a password. – nikitablack Jan 21 '15 at 12:25
  • 1
    The key would prevent the attacker of knowing the password. That been said, this key should only let the software log into the user account. – G4spr Jan 21 '15 at 12:41
  • 2
    plus, if you are really using TLS you can 'avoid' network intercept, but if an attacker has local access to the computer, then the only thing you can do is to make it hard, but not impossible to capture. – G4spr Jan 21 '15 at 12:44
  • 4
    @nikitablack The key can expire whenever a connection is made from another IP or after a certain date (e.g. log in once a month). Both things that are not possible with passwords. – David Mulder Jan 21 '15 at 17:57
-1

This is what i had in mind as i already have built an application like this that works like a charm.

As you are already using TCP you could encrypt all the data that you are sending and decrypt them inside the application.

  1. User logs-in and the data that he has entered the first time is sent encrypted to the server.

  2. Server reads the encrypted data and checks if the login is correct and sends back a reply to the client.

  3. Client reads the data and checks if there is a login success.

  4. Token is stored inside the application so the user wont need to enter the data again.

  5. Each time the user launches the application, the application then first check the login token,and then auto-login while the startup screen of the application is loaded.

Encrypt all incoming and outgoing data if you are planning to make a messaging application, or if it is a web related application then just encrypt the important parts.

Use a 3-way handshake if you would like to use a custom TCP, or use HTTPS if that is what you desire if its web related.

There is only one problem that could mess everything up and that is if the users machine is infected with a keylogger which can read all data sent from the keyboard.(ex. the first time he has to use his login credentials)

I hope this has helped you enough to lead you in the right direction.

  • 2
    You're kinda over complicating things. First there's really no need for manual AES on the client-server communication, HTTPS can already take care of that and is a lot easier to implement. – user42178 Jan 21 '15 at 15:47
  • I agree but i just like securing things. HTTPS is not secure as we have seen in the past. – GaringoXXS Jan 21 '15 at 15:55
  • 2
    But then how do you explain that everyone is happily using HTTPS and so far there aren't been much issues (other than the occasional vulnerability like Heartbleed but that gets patched in a matter of hours on anything important like a banking website) ? – user42178 Jan 21 '15 at 16:16
  • 2
    What you're proposing is effectively sessions that use the password as the session key... which is inherently less secure than a properly implemented session/access token. – Rick Jan 21 '15 at 18:42
  • 1
    Also trying to role your own AES is basically trying to re-implement https which as you pointed out has had security flaws in it. Your own version will have security flaws in it too, the only advantage would be security through obscurity. Every time a flaw has been found (by an upstanding citizen) in https, a patch goes out and it becomes more secure. Who would look for and find the security flaws in your custom system? (only the people who want to exploit it) – Rick Jan 21 '15 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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