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.
Related
So I'm all very new to Java and developing for Android, but I somehow managed to get a successful idToken when logging into my app via Google.
I read on the Android dev site that just ID's are not safe as a modified client could send a fake one and result in impersonation of another user, so I followed their steps to get the user's idToken.
Anyway, is this safe to send over a URL to my server at home? For example, like so (pretend the long string of random text is the idToken of the user):
http://130.155.122.8/api_test/h78e568e7g6589gjkdfhjghdjfkghjkdfhgjkdfhk7hg9867458g74598hg6745896gh49/command
Also, is the idToken even required? Could I just as easily use the user's email address to identify the user (again, it would be sent over an insecure URL, no HTTPS)?
Thanks!
You should use encryption, if someone gets the token from a user they can impersonate that user, in my case, since i can't aford ssl (for now) i encrypt the token using asymetric encryption, and i send it to the server, but ssl is the best way
Generally speaking - No.
A token that identifies you should never be transmitted over an insecure connection (e.g. http). Since on such connections no encryption is used, a third party can very easily monitor the connection and get your token (leading to the impersonation issue).
IANAE, but any security-relevant data (e.g. idToken or password) should only ever be transmitted over a secure (encrypted) connection (e.g. https).
And using the e-mail address does not solve the issue. You simply replaced one identifier for another one. And if anyone ever were to know a user's e-mail address, he could impersonate said user. Stick to the "documented" authentication techniques. If done right they should be safe.
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'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.
A little bit of background --
I run a game server that runs in Java, and a forum that runs in PHP (phpbb). I have the game and forum accounts linked, such that changing the password in the game automatically changes the password for the forum account. The two systems use different password hashing algorithms, and I need to update the password hash on the forum side by using phpbb's built-in functions, meaning I have to call them from a PHP script (rather than running my own code).
In order to do this, I decided to have Java call the PHP script by making an HTTP request to the PHP script whenever the password needs to be changed, to trigger a PHP script that completes the password-changing process for the forum account. However, I don't want to put the plaintext password in any HTTP call, since it might show up in log files and maybe other exploitable areas. My current idea is that when the Java side is changing passwords, it puts the new plaintext password in a database table, and then makes an HTTP request to trigger the PHP script, such that no hashes or sensitive information goes into the HTTP request. The HTTP call would only pass the username of the account to be changed, and a md5 hash of a shared secret plus the username, for authentication. When the PHP script runs, it retrieves the new plaintext password for the user from the database, immediately deletes it, then runs the plaintext password through phpbb's hashing algorithm and updates the forum database.
Under typical conditions, the plaintext password would probably be in the database for less than a second before it is deleted. Ideally, I wouldn't be storing it anywhere at all, but I am not sure how else to communicate the needed change from Java to PHP when I can't predict what the forum's password hash will be, so I need to somehow send the plaintext password to the PHP script that does the hashing.
Any ideas on a better way to do this, or is there any feedback on storing the plaintext password for a very short period of time? I consider the MySQL login to be secure and is not shared with other people or projects.
Thanks!
Don't store plaintext passwords.
If your game becomes popular, it might be a target to constant attacks of hackers
especially if it will contain a monetary aspect (i.e - the case of world of warcraft, travian and others).
In this case, you will need to assume that although you attempt to protect your system,
Someone might hack it, and as a result get sensitive data.
You should use standard encryption mechanisms in order to perform this task (i.e - send the password to forum system via HTTPS for example, in a secure way).
I would also recommend you to explore the comment of #Joshua Kaiser - single sign on may be the key to answer your needs,
and don't try to reinvent the wheel here. I can tell you I Work with kerberos for example,
and Kerberos has a ticket mechanism in which the tickets can be re-used among applications. Unfortunately I dont know PHP, and don't know how pluggable the forum framework to use different authentication modules.
P.S - I posted this answer twice by mistake, and tried pressing "delete post" - I hope stackoerflow takes care of that.
Encryption is the way.
Encrypted connection: Synonym for HTTPS. Pass the data to phpbb using HTTPS, if your server supports it.
Encrypted data: either encrypt the password and somehow store the key (very insecure), or use asymmetric encryption. See the answer to my question for a good insight of how to send the password over a secure channel.
It depends on the database that you're using with Java more than PHP. In PHP use PDO to connect to the different database and manipulate the data. You might try simply having one DB as the primary password storage and the other as salve - depending on reverse encryption mind you.
Have PHP (For example) PDO the text password directly into the Java db in a temp field - specific to the user of course - and then tell PHP to trigger a Java Function to read that column, hash it, update the correct column and delete the temp field.
If done properly, you could have the time-frame of vulnerability limited to a few milliseconds.