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.
Related
I want to create a auto login system for my client-server program.
I have an idea but I think it is very insecure. So.. can anyone explain to me how to do this in a secure way so nobody can get into my account with "just copying files".
My idea:
As the Client registered at the server he get an identifier and a securitytoken from the server. The client and server are saving these in a sqlite database. When the client starts the program he checks if he has a database. If he has he sends the data inside the database to the server. In case the server has got the data the client is signed in.
There are multiple ways to achieve this authentication.
Exchanging a Token is a good idea. The token must be unique for every client in the application, and the server, in a authentication phase (middleware) verifies if the token exist on the database.
If it does, then the request is processed normally. If it fails, then you return a 401 error code.
There are multiple types of tokens. It can be a random token that you might need to check on a DB if that token is valid, or a cryptographically signed token with a private key of the server. This approach adds the advantage that you don't need to check on DB if that token is valid as it can be validated using the server's public key. An example of these are Json Web Tokens https://jwt.io
You must also think on a method to revoke the tokens if you wish that a client no longer connects into your system.
Finally, it's necessary to mention that the security of this system is valid as long as the communication between client and server is encrypted using SSL/TLS or any other method. If you're using plain text communications, anyone in the middle of the network can get your token and send requests on the client's behalf.
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'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 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'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.