I've submitted an application to the amazon app store, and it was rejected with the following details:
Sensitive information like password is echoed in clear text without
encryption
Obviously, not a great thing ... however I've reviewed the application code. The user's password is stored in the private preferences as an MD5 hash (it goes straight from textbox to md5 hash to prefs, and is not logged or written anywhere as plaintext.
When we post requests to our web API (via http), we post a header with the username, and a hash of the following concatenated string (nonce + timestamp + passwordHash) (along with some other bits).
I assume it has to do with the data in the header, but as it's a hash of a hash that we're posting (which the server compares with its own digest of the password he knows), I'm not really sure why they'd have a problem with that.
How can I troubleshoot this failure?
Just to close the loop on this. I ended up emailing amazon, and they gave me more details ... turns out I was submitting the password in cleartext on the registration page. everything else was fine.
We ended up getting an ssl cert and using https to register the user and it was approved. hope that helps someone else out there :-)
Your hashing scheme is broken. By hashing the password and then using that hash like you do, you just redefined what the plaintext password is.
One consequence of this is that anybody who gets access to your database can login to any account, since you stored the plaintext of your derived password.
I'd either:
1) Store the hash(Using bcrypt or similar) on the server. Then send the plain text password to the server and rely on SSL for transport security.
2) Use SRP. But DON'T implement this yourself. It's notorious for being hard to implement correctly. It's very easy to make a mistake and ending up with an insecure login.
Both of them are more secure than your current system.
Related
We implemented a function to issue a temporary password to the user's e-mail using Retrofit. In the tester mode, the temporarily issued password was stored in the user database, so it was possible to log in with the changed password. However, after the production launch, a temporary password is sent to the user, and if they try to log in with that password, a message indicating that the password is incorrect will appear. When I check the user database, it is confirmed that the password has been changed to a temporary password issued by our side. What's the problem?
I am currently using Retrofit and Nodemailer.
Check the Login API Using Postman or Insomnia. If the issue exists then the Problem with the server side.
In Server side,Check the same encryption scheme & salt(used to encrypt temporary Password) is used while checking the password. Passwords won't match if different encryption scheme(& salt) is used while creation and checking.
If the problem is not in server side, then Check the retrofit is using the correct authentication method & Exception is handled correctly in retrofit
I'm creating a android app which requires login and the authentication will be done against a node server.
HttpURLConnection is used with the POST and I'm using HTTPS. But my question is, since username and password are sent to the server as url parameters, do I need to add more security measures; like encrypting those two parameters(Using Base64)?
I've tried to use Authenticator.setDefault(new Authenticator(){}) but I'm not user implementing that only would be enough.
The URL parameters are encrypted thus protected in transit but are probably logged by the system so the username and password will probably be in the log files. It is best to send then in thee POST data, not as part of the URL.
What you can try is encrypting the data and then send it to server and on server side the data should be decrypted . In this way the security of your app will be maintained.
See this
I'm developing an application (as a part of team) for android that interacts with server (asp.net web service) for synchronize and update information in client side.
for preventing attack to server we use SSL connection and also authenticate users with soap header message contains username and password.
here is the scenario for synchronization:
users send web service request with header contains : username , password , time of request , and(for preventing man on the middle attack) hash code of all three parameters(username+password+time) as message signature
web service check that :
is this a new message by checking the signature of message stored in server
if this is a new message (and its not duplicated) then check that signature is true by hashing all three parameters(username+password+time)
then check expiration time : is the message new ( in 5 minute ) for expiring old messages
Authenticate username and password
validate datatype and length of parameters ( in this case only time of device's last sync )
response to request
device get the response as xml file
the question :
because of this scenario we have to give user's devices authentication information so they could interact with server in future and also we don't want to get any information like username and password from users ( for user experience purpose! )
so we build a Web Handler Captcha in server and when users are new, we send them a captcha image generated by their device code(it is uid generated by device something like : https://www.server.com?appid=00000000-0000-0000-0000-000000000000 ) and when if user sends the correct captcha to server we add a new user to our database ( auto username and random password ) and save to the android's account manager for future use
in your opinion is this a good approach for authentication and security?
Thank you for tips
Https and a method to get a sessionId is enough security for most apps, anyhow my opinion:
Unless you include a secret within the hashed variables a "man in the middle" can change the parameters and forge a valid hash.
I would recomend a registration method. It's going to take device information as parameter, and the captcha if you will.
It's going to return a deviceId and a deviceSecret. The deviceSecret must not be transmitted again, just used as part of the hashes.
Also consider using a counter instead of time. It can help against replay attacks and it's easier overall.
I'm writing an Android email client app, based on the Javamail API. I can log into GMail accounts from it, but I want to make sure that the login process is actually secure.
So I use code like this:
Session session = Session.getDefaultInstance(props, null);
Store store = session.getStore("imaps");
store.connect("imap.gmail.com", "usernameEditText.getText().toString()",
"passwordEditText.getText().toString()");
Since I am not storing the passwords themselves at any point (they are passed directly from the text boxes and stored in Google's servers), I'm pretty sure I shouldn't have to worry about hashing and encrypting things as if I was keeping the passwords in my own DB--but is this secure at all, or can the user/password combination potentially be intercepted as the packets created by my app are sent to Google's servers?
If I understand correctly, the "imaps" store ensures that this is an SSL connection and so the traffic should be encrypted, but I want to make sure I'm not misunderstanding things.
Thanks!
Don't worry. All data in IMAP over SSL connection are encrypted. However for sending email, the Transport.send method will use the default transport protocol,
which remains "smtp". To enable SMTP connections over SSL, set the
"mail.smtp.ssl.enable" property to "true". This is usually the easiest
approach.
Alternatively, to change the default transport protocol
returned by the Session.getTransport() method to SMTP over SSL, set
the property "mail.transport.protocol" to "smtps". To change the
transport used for internet addresses (as returned by the
Session.getTransport(Address) method, and used by the Transport.send
method), use
session.setProtocolForAddress("rfc822", "smtps");
You can find more information in Notes for use of SSL with JavaMail.
I want to ssh into a server from behind another ssh server. The gateway server requires a username/password and I can do this. I am using a tunnel to get into the next server, but this one requires only an ssh key. I've generated the key through PuTTY, so it exists for my username but I'm not sure how to retrieve it for my Java program. Is it a configuration? i.e. setConfig("userauth.publickey", "com.jcraft.jsch.UserAuthPublicKey") then how do I use this or something else? Documentation seems to be sparse and I appreciate any help. Anything I've tried gives me an error :"Auth fail" when I connect this session
Thanks!
The tunnel method I use is: http://sourceforge.net/apps/mediawiki/jsch/index.php?title=ProxySSH so thanks to the guy who wrote it!
For context, I'd like to read/write to a server at my school from my Android phone.
To enable public-key authentication, you have to use one of the JSch.addIdentity methods.
These take the public and private key in the OpenSSH key format - so make sure you export it from PuTTY in this format. (JSch doesn't understand PuTTY's native format, though you could write an adapter implementing the Identity interface, parsing it yourself).
The identities added to JSch are global, not per-session. This is normally not a problem, as JSch will try all authentication methods which are supported both by itself and the server in order, and public-key authentication is normally before password authentication.
All authentication methods need a user name (usually the name of the account to be logged into).
With public-key authentication, the public key must be somehow previously available to the server. For OpenSSH's sshd, the public key should be listed in ~/.ssh/authorized_keys. (If you have only one public key, simply copy it to this file, if you have multiple ones (each of which will be allowed), each should be on one line.)
So it should work out-of-the box after setting the identity.
If you want to make sure the first session uses password authentication and the second (tunneled) one uses public-key, you can use the per-session configuration, overriding the global one:
tunnelSession.setConfig("PreferredAuthentications", "password");
innerSession.setConfig("PreferredAuthentications", "publickey");
(These are comma-separated lists, here of one element each.)
About the ProxySSH example, that is by me (with some help by JSch's author, Atsuhiko Yamanaka). I should add this information to the Wiki page, maybe.