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.
Related
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.
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 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 want to know the way to query a database to authenticate a user over network. I am not asking for any algorithm which is described in the posts like this Handling Password Authentication over a Network.
I have also taken a look at sync-adapter in android but I need authentication to be successful over the network before going ahead to Sync.
Here I explain it. I want to do so to avoid this problem.
I do not want a user to replicate GBs of data from server first and then authenticate in application db. I just that user will be authenticated over the network and then the data relevant to him only will be replicated(filtered replication)/synced on his device. So while authentication no data will be available on local device database.
Yes, What you can do is by using rest api there are few good libs avail for android.
Use those to send auth request and once it is authenticated on the server return true.
Once this done you query the server to get user data, then once you retrieve correct data form the server store it to your database, once stored get the the timestamp or the time and save it to ur database, and for the next time use this for query server if there are new record created in the server after this time stamp the return data or return nothing. so this will save your extra work.
Rather i would suggest you to implement google cloud messaging server on the server to notify.
Form more detailed architecture refer this tutorial :
http://developer.android.com/training/sync-adapters/index.html
http://developer.android.com/training/cloudsync/index.html
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.