In my app, the user should be able to login regardless whether they are online or offline, so is it possible to add offline authentication capabilities to my app, because I believe the package google_sign_in only does online authentication.
If all you're doing is asking for an email & password, that's fairly simple to check against and you can do it without having to delve into native code.
However, you'll also want to store the password information securely so that will require a little more work.
During registration:
Ask for username and password, then confirm password
Hash password securely (use an algorithm meant for password hashing like PBKDF2, SCrypt, or Argon2, and use a salt. There'a ton of stuff out there on the internet why this is important). There's a plugin for this: password.
Store this hash & the username as securely as possible - flutter_secure_storage seems a good a bet as any although only supports android 4.3+.
Use the generated encryption key to encrypt any data you need saved securely (maybe the encrypt package could help but I'm not 100% sure how complete or secure it is).
If you instead want your user to log into a server the first time and save the password as well, this should be more or less the same process except that you verify that the server accepts the password before/after hashing it.
During login:
Ask for username and password (or hopefully just password or you'll annoy the crap out of your users =D)
Retrieve previously stored password hash + salt
Verify against previously stored hash + salt
Use generated encryption key to decrypt data etc.
A few other things... make sure that the password entry doesn't support autocomplete or the user's keyboard might save their password. If you have a button to show the password you might want to think about blocking screenshots somehow while it's being shown (that's native though). And never, ever store the password in plain text! Using a hash means that at least if an attacker gets in, they won't be able to see the actual password.
Note that while this should work and should be at least moderately secure, don't treat it as a 100% secure solution. You should always get an expert opinion on how to implement your security as opposed to a stranger on SO =P.
There's also a bug open against the flutter google auth plugin about this so it might get resolved at some point that way.
And there is also the local_auth plugin which supports TouchId/FaceId on iOS and fingerprints on android - however, it will only work on android 6+ and with devices that have a fingerprint reader so you may need to have the username/password fallback anyways.
I'd be happy to answer any questions you have about this.
Related
I am trying to authenticate users for my Flutter app with hashed credentials. That is I'm hashing them before requesting auth with .login(). Problem is that the hashing packages I'm looking at using both have a function for checking the plain text password against the stored hash. This works fine for offline auth, however when sending hashed credentials to Parse auth gives invalid username/password error of course, because the algorithm changes after app restart.
The local side of things is pretty easy, now I'm caught wondering if it's secure to send users credentials in plain text through https Parse request?
I can't see a way to verify equality of hashing just entered credentials with parse because the hash is always different on app restart. Do I have any other option here?
Can someone give me some guidance here please?
I want to do the following
User signs up to IOS app and provides username and password
Make a server call and store password in server database
When user logs in in the future, retrieve that password and check against the password that the user entered.
How can I do this in the most secure way possible? I was thinking of encrypting the password when storing in the db. When the user logsin, use the same encryption algorithm and compare against the db encrypted password.
NEVER ever store user credentials in encrypted (reversible) form. Currently best known way for checking user credentials is slow salted hash
for what and why please read https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
However, don’t try to invent your own algorithm for repeated hashing.
Choose one of these three well-known ones: PBKDF2, bcrypt or scrypt.
As already commented you may outsource the user authentication to some reliable service (google, fb, aws cognito, ibm appid,...)
Have you tried looking into databases? I know that Firebase has an authentication component of their database for ios development, and you might want to try to look into it or other databases. Check out firebase at: https://firebase.google.com/
I am developing an app which uses several API services, the API requires that I provide username and password for API transactions, unfortunately no API token :-( in-order to automate I need to store username passwords somewhere, preferably database, I cannot use hashing because I need to send the username/password to authenticate and process API request, hence I am wondering how to go about it.
If I use Zend\Crypt to encrypt and store the password in database and decrypt whenever required, would this be enough for security? is there something else I must consider?
Looking for pointers.
PS: I am using ZendFramework2 with Doctrine/MySQL for the app.
Usually you would use a token mechanism (like OAuth). If that's not possible, one would use TLS/SSL client authentication.
However, if you rely on plain passwords (on the application-level, I still guess the username/password tupel is transmitted over a secure connection!) and you want to store them encrypted, you have to think of a meaningful mechanism to get an encryption key for your scenario. Just generating an encryption key and storing it on the same machine in plain does not provide more security.
Without more information on your scenario it is hard to make a suitable suggestion.
I am working on an application that uses a private web service.
We currently use a bundled client certificate to enable 2-way SSL connectivity however the password for the certificate is in the code and it is a concern that this could be de-compiled and used with the (trivially)extracted certificate file for nefarious purposes.
Is there a method by which I can pre-load a password into the application keychain for distribution with the app so that the password is never left in the open?
No matter how you put your password into your binary, there will be someway to exploit this, be it with debugging tools, code analysis etc.
You better treat your web service as open... maybe unlikely to get not properly authorized requests in the very next future, but basically you give away access to the public.
Keychain should be encrypted with user specific key, and this you obviously cannot do - or you would be able to read everyones data anyway.
If you really need to protect it, you probably need user accounts on your server... if this is more secure than obscurity it up to you.
I am planning to store a password in my Native app (Android and iPhone). Should I store them after encrypting it ? or can I store it without any encryption? Are they really secure?
Any jailbroken iPhone will give any user access to the application's Documents folder. So, yes, it's insecure.
Additionally, if you put the password inside the code, you're still weak, as someone can decompile the program and find the key. What I'd recommend is a proxy.
For example, we have an application that connects to Facebook's API on the phone. However, we don't want to store our Facebook API private key on the phone, because then any user who reverse engineers our code could hack our Facebook application!
So, instead, we store the Facebook private key on a (secure) proxy server. When the device needs to interact with Facebook, it contacts the proxy, asks the proxy to log-in, and then the proxy gives a session key to the device to use directly with Facebook.
Certainly, it's still hackable - but you won't lose your private key in the process, and instead, the only thing your user could do is do the same things you do in your proxy server API.
Could you give us a little more information about what you're trying to do?
I would store it encrypted.
If someone would read your password he/she could simply use it. If it is stored encrypted, that person would need to decrypt it before usage.
Stored passwords are not safe at all. Determined user can root it's device and access any database and preferences. If you encypt password, your application can be decompiled to get decode function or step-executed until decrypted password is stored somewhere in process memory.
It doesn't mean you shouldn't encrypt passwords - use any symmetric encryption and initialise key in some non-trivial way (i.e. arythmetic expression). This will prevent script-kiddies and casual programmers from reading passwords. Just remember if some really want them, he will get them anyway.