I want to develop a thick client app (instead of using jsp/server side) which I will provide a login panel upon launching of my app. I am not sure whether it is the correct approach (in terms of security) so would like some comments.
Authentication will be through a back end database. That is, I create the user at the database level and my thick client app will authenticate with database using the provided user id and password. Is this method safe enough? or do I need a real session/password management api to do this?
How do I keep sessions in a thick client app like this? Also, if I want to encryption traffic between my app and the database server, should i just use JSSE or similar? Is there a way to encrypt data instead of the communication channel? I believe my database server need to also be able to decrypt my encrypted data.
I create the user at the database level and my thick client app will authenticate with database using the provided user id and password. Is this method safe enough?
Yes, provided you do as follows:
Hash the password in the database, rather than encrypt it.
Validate the user by querying the database SELECT count(*) FROM USERS WHERE USERNAME=? AND PASSWORD=MD5(?) or whatever hash algorithm you use. Note that this technique deliberately doesn't tell you whether the username or the password was wrong, so as to avoid any possibility of leaking that information to an attacker. The idea is that it returns either 1 or 0.
or do I need a real session/password management api to do this?
Not really.
How do I keep sessions in a thick client app like this?
If you mean a session that persists between logins, keep it in the database. If you just mean a session that lasts between login and logout, just keep it in an object that is released on logout.
Also, if I want to encryption traffic between my app and the database server, should i just use JSSE or similar?
Yes.
Is there a way to encrypt data instead of the communication channel?
The database can do it with encryption functions.
I believe my database server need to also be able to decrypt my encrypted data?
What encrypted data? If you mean the stuff transmitted over SSL, it will be decrypted automatically.
Related
I'm trying to make a password manager app. In which on start you setup a master password that will lead you to the MainActivity, where you store other passwords.
How do I store editText input for the login?
I see that people are talking about not storing it, and making it encrypted.
You should use some server side storage for those passwords, as the user can anytime go to app settings and Clear Data
That would erase each and every password you've stored encrypted or not.
For starters, you can use web services . Make a small server side application in java or php for the webservices.
You can store in local and on server both. Check local database first, if you don't find the passwords there then check the server, if you do find passwords on the server then sync with your local db. In case user decides to Clear Data for that app. Your passwords will still be available on server.
I came across this online document, and from there there is slide about GWT Offline authentication:
When online, authentication is done by the server.
We should then be able to re-authenticate him/her without the server.
Be careful ! Local storage completely unsecure !
We thus store the user’s password in the browser, salted and
crypted with SHA-3.
Find a Java SHA-3 implementation, copy-paste in the project :
String shaEncoded = SHA3.digest( String clearString );
Offline HTML5 apps with GWT 18
The questions are:
Is it really possible to securely authenticate a GWT application with this approach? If it's SHA-3 encoded would it really make it secure?
When user gets authentiated in the browser, then user uses the offline app, say save stuff, then surely it is just stored in the HTML5 Storage, however with the User info embedded perhaps in anything saved. Thus, when app gets back online, it will sync to the server. How is this secure? Would the server just accept that the thing it is syncing really is from the right user?
There is no special case for offline regarding authentication. It works the same as with online.
You will usually have a Cookie with session information stored in your Client's browser which is used to authenticate the client with the server (when you are making a request).
As long as the session information is persistent on the backend, you can re-authenticate the user.
You must not store the password on the client side. Its is enough to store some session information on the client (either in a Cookie or LocalStorage) and use that to authenticate the user.
Actually you are not storing the password itself in the browser, but its SHA-3 hash.
From a cryptography perspective this approach is very secure as it is not easily possible to retrieve the original password.
Just note:
Your code will be stored on the client side and every source code on the client can be tampered with. So also a malicious user might be able to read and exploit it.
But don't worry, for the ordinary use case of an offline usable application, this is secure enough.
What I would do for long running server sessions:
Generate a random ID on the server side, associate it with the user and store it i.e. in a database.
Set the ID as a cookie on the client and re-authenticate the user whenever he is not logged in and still has this ID in a cookie.
To limit the amount of time you can add a timeout value on the server side after which the ID is discarded.
I'm currently developing an android app where the user has to fill out and successfully send the data of a few text fields to a recipient/server, to enable a feature.
The big issue is how to do that in a secure way to be protected against e.g. decompiling. My concern is not the security during the transport but rather the security of the transport medium.
What I've thought/read so far:
I could send the data via mail with the Java Mail API.
First of all, I don't want require that the user has to enter his mail credentials and SMTP server.
That would mean that I have to include the credentials to a mail account in the app, though.
To avoid the situation that somebody decompiles the app and takes over my mail account, I thought of encrypting methods, but even if I would save the aes encrypted version of the password, the attacker could decompile the app and could add a syso to output the decrypted password.
The same applies to OAuth authentication because I have to store an authentication token.
In addition to the mail version, I read something about getting the password with a POST request from a web service, which doesn't seem safer at all.
I could search for free smtp server without the need of credentials, but I want something I can rely on instead of waking up each day and looking if the service still works.
Send the data to a web service.
Okay that would require more work for me, but I would accept that, if there would be a solution without saving the credentials in the app or having a web service which accepts data from everybody.
Have I overlooked something? Or is there no safe method without asking the user for his mail credentials or google account etc. ?
OAuth would probably work. The nice thing about OAuth is that if a token is compromised it can be revoked on the server side.
You could create a web service that accepts TCP connections on some port. You could have some authentication mechanism for example Digest authentication that would be carried out before accepting data.
Another option would be to use an API such as Golgi. Golgi requires a developer key, app key and app instance id to connect to the servers and send data. In the event these credentials somehow get compromised you can simply change the app key and push a new version of the app through the Play Store.
I am developing an app which sends email. I use this to send message, but it requires username and password of my gmail account. So, I need to store them in app. How to protect them from malefactors?
Don't store passwords use tokens like a session cookie on http. Sessions can been revoked server side by user actions without harming other sessions.
A password can been read out (even if it is encrypted you need to send it unencrypted to the server hopefully via TLS) and if the user uses that password on multiple sites the user will get a problem.
I don't see the adequate answer, so I decided to get rid of storing password within my app. I just send request with necessary parameters to my server. The server gets these parameters, creates email and sends it to the recipient by using PHPMailer library. I used the code from this to send request to server. I hope it helps someone else.
This is just a suggestion but a little helpful. As other says SharedPreferences is fully secured but if we save data in SharedPreferences as encrypted format then it should applicable.
here is a examples and also MessageDigest will help you a little here.
Note: This question is directly proportional to security things, so I never recommend any of my answers. But it can be helpful.
You can use SharedPreferences for this but beware saving passwords is usually frowned upon even if highly encrypted.
Even in a PC app saving a password always warns you that the password is saved locally and is not secure from attacks.
I have an Java desktop application which connects directly with the DB (an Oracle). The application has multiple user accounts. What is the correct method to send the user's password (not DB password) over the network? I don't want to send it in plain text.
You could connect over a secure socket connection, or hash the password locally before sending it to the database (or better, both) - Ideally, the only time the password should exist in plain text form is prior to hashing. If you can do all of that on the client side, more the better.
You can use SSL connection between Oracle client and Oracle database. To configure SSL between oracle client and server using JDBC:
At server side:
1) First of all, the listener must be configured to use the TCPS protocol:
LISTENER = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcps)(HOST=servername)(PORT=2484)))
WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/server/wallet/path/)))
At client side:
1) following jars needs to be classpath
ojdb14.jar, oraclepki.jar, ojpse.jar
2) URL used for connection should be:
jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=servername)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=servicename)))
3) Following properties needs to be set (either as System property (-D options) or properties to connection)
javax.net.ssl.trustStore,
javax.net.ssl.trustStoreType,
javax.net.ssl.trustStorePassword
Reference: http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/wp-oracle-jdbc_thin_ssl_2007.pdf
Agreed, never send the password the user chose in plaintext. However, short of using public key cryptography, if you email them a password, it's going to be in cleartext. One thing I've seen often happen is that when the user forgets the password and requests it being sent to them, the system generates a new password and sends that one to the user. The user can then change the password.
This way, the password the user chose (which the user might use elsewhere) is never sent, while their temporary password is sent in plaintext, they should change it soon after.
If you don't want to send the data in plain text, use encryption !!!
Use some encryption algorithm such as AES, Twofish etc.
You must also take into consideration where your client and server are. If they both are in the same machine, there is no use of using an encryption. If they are in different machines, use some encryption algorithm to send sensitive data.
If YOU are checking the validity of the passwords, you can just send the hash of the password. Beware that this method will work only if you are comparing the password yourself. If some other application (out of your control) is doing the validation job, you cannot hash the password.
If you connect directly to the DB with no middle layer, you should consider using a DB user for each real user, because otherwise you can't really secure the access of the application.
If you connect to Oracle with ORa*Net the user password is automatically encrypted (since Oracle 8) however it might fall back to unencrypted passwords in some situations. This can be disabled with ORA_ENCRYPT_LOGIN=true in the environment of the client.