I use the Spring security for Java web applications and I have written an authentication provider which is working without salt and now I want to either add salt or alternatively use the built-in algorithms with Spring security that appear to be SHA and that can use salt that is specified with XML. In my case I didn't use SHA but AES and the input password is matched against cryptographic string that were encoded e.g. �[�s�E�qh�%"5%��g"2T��$�` that will match against back-end in this handler.

public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String name = authentication.getName();
        String password = authentication.getCredentials().toString();
        AdministratorAccount administratorAccount = administratorAccountService.get(name);
        CryptographyProviderAES256 aes256CryptographyProvider = new CryptographyProviderAES256(256);
        byte[] mockSecretCode = new StringBuilder().append("qwertyuiqwertyui").toString().getBytes();
        byte[] encrypted = aes256CryptographyProvider.encrypt(password.getBytes(), mockSecretCode);

        //TODO: salt
        if (administratorAccount.getPassword().equals(new String(encrypted))) {
            List<GrantedAuthority> grantedAuths = new ArrayList<>();
            grantedAuths.add(new SimpleGrantedAuthority("ROLE_USER"));
            Authentication auth = new UsernamePasswordAuthenticationToken(name, password, grantedAuths);
            return auth;
        } else {
            return null;

Should I use SHA instead that is built-in with Spring security and can be added with XML instead? My Account class has variables for password and salt, how should I implement a salt? Should I generate a salt from time + random when creating the account like this:

 final Random r = new SecureRandom();
 byte[] salt = new byte[32];

1 Answer 1


Do yourself a favour, don't try to invent your own password hashing functions. In the field of cryptography in general, and of password hashing in particular, amateur constructions are almost invariably weak, because you cannot test for security. Any programmer can make some code which is sound, i.e. which works, but no programmer can make sure that what he produced is secure.

Professional cryptographers cannot invent secure algorithms by themselves either; however, they know it. So when they produce a new algorithm, they show it to their fellow cryptographers, who do their best to try to break it. If the algorithm survives for sufficient time (several years), then the algorithm is deemed "probably secure enough to be used in production".

Unless you have your own cryptographer team and can afford to wait for a few years, you really need to rely on existing password hashing functions which have undergone this treatment and are still alive to talk about it. This basically means bcrypt or PBKDF2. More details here.

Also, don't use password.getBytes(). That getBytes() method uses the default charset, which depends on the current locale. This method is a great way to make code which breaks when used in another country. Instead, use an explicit charset, as in password.getBytes("UTF-8").


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .