Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I\'m developing an application. The user must enter his credentials which will b

ID: 656216 • Letter: I

Question

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.

Explanation / Answer

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.

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote