Saving secured passwords is somewhat more involved than authenticating against them. Part of the reason is that we'd
like to use the same PasswordEncoder
instance during registration that we used during login, partly just
because it's "cleaner", and relatedly, because it allows us to avoid having to coordinate two separate PasswordEncoder
instances should we decide to switch from SHA-1 to MD5, or add salt, or whatever. Basically it boils down to our being
good adherents to the DRY principle.
Unfortunately, the namespace configuration for authentication-provider
doesn't accept an
externally-defined PasswordEncoder
bean; you have to use the password-encoder
namespace
element inside of authentication-provider
. So instead of using the namespace configuration, we're going
to drop back to good, old-fashioned bean configuration.
PasswordEncoder
and DaoAuthenticationProvider
<?xml version="1.0" encoding="UTF-8"?> <beans:beans xmlns="http://www.springframework.org/schema/security" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:p="http://www.springframework.org/schema/p" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd"> <-- 1 --> <beans:bean id="accountDao" class="example.HbnAccountDao" /> <-- 2 -- > <beans:bean id="userDetailsService" class="example.UserDetailsServiceImpl" p:userDao="accountDao" /> <-- 3 -- > <beans:bean id="passwordEncoder" class="org.springframework.security.providers.encoding.ShaPasswordEncoder" /> <-- 4 -- > <beans:bean class="org.springframework.security.providers.dao.DaoAuthenticationProvider" p:userDetailsService-ref="userDetailsService" p:passwordEncoder-ref="passwordEncoder"> <custom-authentication-provider /> </beans:bean> </beans:beans>
In the code above, we begin by creating a data access object for user accounts 1. Next we
create an implementation of Spring's UserDetailsService
interface, which we've called UserDetailsServiceImpl
2. UserDetailsService
is essentially a service provider interface for the DaoAuthenticationProvider
;
it allows the latter to obtain UserDetails
instances for authentication purposes. Third we create the PasswordEncoder
itself 3; in this case we're using ShaPasswordEncoder
, which hashes
passwords using SHA (the default strength is SHA-1). Finally, we're creating a DaoAuthenticationProvider
4 and injecting it with the userDetailsService
and passwordEncoder
we created previously. We also include a custom-authentication-provider
element to register our
authentication provider with an AuthenticationManager
hiding in the background.
For the curious, the AuthenticationManager
in question is ProviderManager
, a provider-based
implementation of the AuthenticationManager
interface, and it is automatically created by the http
element unless you've already defined one explicitly. See figure 1 for a class diagram.
That takes care of configuration. Let's see what we need to do in order to save registrations with a hashed password.
There are two updates you'll need to make to your AccountServiceImpl
bean. The first one is that you'll
need to provide a setter for a PasswordEncoder.
And once you create that setter, go back to your
application context configuration and make sure you're actually injecting a PasswordEncoder
into the AccountServiceImpl
bean.
The second update is to modify your registerAccount()
method in AccountServiceImpl
so that
it hashes passwords:
public void registerAccount(Account account) { accountDao.save(account); // 1 String encPassword = passwordEncoder.encodePassword(account.getPassword(), null); // 2 account.setPassword(encPassword); // 3 accountDao.save(account); // 4 }
First we save the account with the plaintext password 1. There's a reason for saving the account before actually hashing the password, but we'll have to wait until later in the recipe for the reason why. Then we hash the password 2, update it on the account 3, and save the account with the new password 4. The account now has a hashed password in the database.
Good job! You're now saving secured passwords into your database, and you're able to authenticate against them.
But I'm afraid that it's time for some bad news.
Our new password storage scheme is off to a good start. It certainly prevents casual observers from accidentally seeing user passwords. But it does little to thwart the efforts of a semi-determined attacker. Let's talk about the dictionary attack.
To understand how it works, recall that hashing different strings generally results in different hashes. We can use that fact to create a big lookup table for a dictionary of potential passwords. The lookup table takes a hash and then returns the string that generated it.
As luck would have it, we don't even have to create our own lookup table. Helpful folks on the Internet have already done it for us. For instance, go to
and enter the MD5 hash we presented earlier; namely,
3af00c6cad11f7ab5db4467b66ce503e
Voilà! You've unhashed a hash. This is called a dictionary attack.
If an attacker were to acquire a list of hashed passwords, he could make quick work of it using a dictionary of the sort just described. In some contexts that might be very bad.