Also have a look at
OWASP password storage guidelines. OWASP is an excellent site for all kinds of web security guidelines.
Which layer?
Password restrictions, forgot password handling, etc are all responbilities of the business logic. The UI too needs to know character and length restrictions. So I handle all these in the Service Layer.
In my opinion, they don't belong in the data layer; that layer should be only for dumb storage and retrieval operations.
Separate user details
One good practice I've not seen mentioned anywhere - not even on OWASP - is to keep the credentials separated from other user details (like email addresses). Perhaps in separate databases, or atleast in separate tables with different authorizations.
If you've read news reports of large website hackings, the spokespersons invariably claim something like "<x> million passwords/hashes were compromised, but
no other user details were compromised".
I become skeptical everytime I read that, because just about every CRUD webapp out there starts off with a "User" class which has all details, and a UserDao class which stores it all along with the user salt and hash in the _same_ USERS table.
So how "no other details were compromised" is beyond me. Nevertheless, I hope it's true and I think it's a good practice if true.
Complementary operations
Depending on the scale of your website, in addition to core authentication, you may also have to think about complementary operations which are common to any web app. For example, periodic database backups may inadvertently leak credentials if backup hard disks /tapes are not physically secured, or are thrown or sold away without wiping/destroying them.
Negligent or rogue internal employees like sysadmins or developers may access the credential database and damage or steal it. So strict database and table level authorizations are required. All database access attempts should be logged, and this log itself should be secured to prevent anybody covering their tracks.
So, there are many aspects to it than just password storage.
Banks
As for banks, they are governed by PCI DSS rules, and possibly additional rules of the country specific banking regulator. In practice, they (try to) follow all the best practices documented in OWASP - not just related to password storage but also authentication and authorization in general. For example,
multi factor authentication. Whatever they implement should finally be certified by the PCI DSS process.
That said, my bank (a reputed international one at that) restricts passwords to 16 characters and does not accept special characters! So be skeptical about using banking systems as a role model.