How can I improve the creation of a password in Android

Question

I am developing an app in Android Studio in Java. The problem is that my app has a login, therefore also a registry, but I would like the user not to put passwords of pure numbers, and I am looking how to put in password restrictions.

if (correo.equals("") || contraseña.equals("") || nombres.equals("") ||
        apellidos.equals("") || edad.equals("")) {
    Toast.makeText(getActivity(), "Favor de llenar los datos completos",
            Toast.LENGTH_SHORT).show();
} else {
    if (!Patterns.EMAIL_ADDRESS.matcher(correo).matches()) {
        Correo.setError("Correo Invalido");
        Correo.setFocusable(true);
    } else if (contraseña.length() < 8) {
        Contraseña.setError("Contraseña debe ser mayor o igual a 6 digitos");
        Contraseña.setFocusable(true);
    } else {
        RegistroAdministradores(correo, contraseña);
    }
}

I only have that security "Parameter" which is the one that is less than 6. I have tried looking for some libraries or the same if condition to see what can be done, but I can't get it.

Answer 1

Where is this password going? If it is just to unlock a local database (your app does not communicate with a server at all) then there is no point to a password; their device is already highly personal. If you want to add an additional layer, the android API has tools to ask the user to re-unlock their device, and you can check if they have a lock in the first place.

Android devices have face recognition, fingerprint unlock, and more. Use them. By asking the device to re-unlock.

If this is heading to a server, the check needs to be done on the server and not in your app. You have to assume the owner of the device hacks your app if they want, you don't actually control their hardware; you do control your server.

To do safe passwords on a server, oof, there is a ton of ground to cover:

• As per NIST standards, require 8 characters minimum and require nothing else. If you require 'a capital letter', they will capitalize the first letter. If you require 'a digit', they will add a 1 to the end, add their birthyear, the current year (to the end as well), or replace an o with a 0 or an a with a 4. These kinds of additions are easy for a computer to guess and hard for a human to remember, i.e. as for as password policies go, idiotic (yes, a lot of companies and standards mandate them. Turns out a lot of standards are written by dunces, I guess. It's objectively bad security to do this). Ask for a symbol, and it'll be a !, and it'll be at the end, for about 90% of the folks you force into doing this.
• When storing the password on your server, use a salt+pw-hash setup. If the user enters password 'iloveyou' (which about 5% of your users will, it is the most common password onb the internet), then you generate some random text, say, 129dajg0an. Then, you hash '129dajg0aniloveyou' with a hashing algorithm explicitly designed for password hashing, so do not use SHA256, do use BCrypt or similar. Store in the database 129dajg0an and the hash result. Now you can check a password again (do the same procedure again, check if the hashes are identical). Use proper security to do so - primarily, don't use the normal comparison operations which stop the moment a mismatch is found, because the time taken could be used to derive some info. Use a secure hash comparator algorithm (keep going and compare every character even if it's already clear it is not going to match). This means that I can't identify the 5% with iloveyou (without the salt factor, it'd be the 5% of the accounts that all have an identical hash, those are the idiots with a common password) - I can't use my bitcoin rig to crack your database if ever I get my hands on it, and then use those passwords on other sites (because users will reuse passwords).

This is all very complicated and you're going to do it wrong when you're a wintered expert who has been doing this for years. Imagine how bad it'll be if you're new to programming. Fortunately, all this salt and bcrypt and cryptographically secure hash compare stuff is baked into easy to use libraries.

I really want to protect the user from picking dumb passwords

The only non-idiotic (idiotic defined as: Gets in the way of users doing it right, e.g. with password vaults, or with long sentences of nonsense words which is vastly more secure than short sequences of symbols and numbers and caps and lowercase!) way to stop bad passwords is to use crackerbots: During downtime or just at a low but continuous pace, some code is continuously running on your server that tries to crack all passwords in your entire database. There are various tools out there that do this. They are smart and use common passwords (princess, dragon, iloveyou, abc123, that sort of thing), prefer using likely birthdates (19xx and 20xx are waaay more common number sequences than anything else), and so on. When they crack one, update your db tables so that you can tell the user: Hey, your password was really weak, pick a new one and do a better job this time.

This is all quite a bit of effort which is why most sites do not appear to do this. But all the simple solutions backfire (in the sense that they actually make the security of the operation worse and not better and are thus getting in the way of the user's convenience and make it worse - a lose lose 'solution' that is therefore best not implemented at all).

An additional trick you can do is to use the hibp API to check if the password the user chose is known (has shown up in plaintext db leaks before). If it has, force the user to pick another password.