There's a few things I don't get here, and probably one or two things worth adding:
- hashed password is encrypted with
private key stored as CONSTANT in
As a "CONSTANT" - what does that mean? Is it hard coded? How is it protected. I agree with other posts that a salt is a good plan - if you salt and hash the passwords, I don't see a need for the encryption on top of it. And - if the private key for your encryption is stored in a flat file or hard coded in the app, you have a weakness there. Recommend finding a way to better protect this key.
In a number of places you mention that you're tracking behavior "per device" - what does that mean? How are you determining what the device is? You're implying a type of device authentication here, and from what little I know about this area, most ways are immensely spoofable, and the ways that are not require issuance of devices from a trusted point, which can greatly change your model of operation.
In places where you say "per device", you're going to have to think through what it means if the device is faking your system. Also, if you have decided that "IP Address" = "device", then you may have to consider numerous situations where the user's IP address is changing through no fault of the user.
- allow login history to be scrubbed of old devices
Is that something you are fully prepared to support? Scrubbing, say, a cookie is pretty easy, but do you mean all parts of memory? Personally, if I were making this promise, I'd bound it some way so that if login information was put someplace strange by the OS, that it wasn't a breach of what my system had promised the users.
I also see some issues:
- How can a user recover from a lost/forgotten password?
I see you citing a fairly involved process for password change. If this is a casual web system, I would bet money that this will be your least used feature. Instead, user's will drift away from the system, only to return and need their passwords and have completely forgotten them (or they wrote them on a sticky note on their screens... that's even worse).
You'll need a way to do password recovery/reset that fits your high-protection model. Is it staffed by a person? Do they have backup questions to answer? Do they get a reset password emailed to them out of band? Each recovery mechanism has risk, and generally less risk = higher cost - for example, my credit card company's ultimate identity check for issues like this is a painful Q&A with a live person about my purchasing history. Very good, but expensive in terms of that person's salary.
- Simple way for users to vet the system
The credential presented by the server in SSL should be good enough, but very few users are PKI savvy enough for that. I know that big financial institutions have started making use of words and pictures selected by the users that users are supposed to verify during login. The whole goal here is to avoid a situation where a phisher could send your user an email directing them to "paypa1.com" (a number 1 not an l), and get their passwords. Since you do have features that accommodate remote login, your attacker will then be able to use a legitimate user account from any system.
These two issues probably aren't the only human-oriented processes you'll need to think through - do you log accesses? Do you have a plan to separate login auditing from administration privileges? How much access do admins have and how is the system protected from them? Are there any other social engineering attacks that might work?
So far, what you outline is tech-heavy, and human-light - you're talking about a couple of mechanisms that may have usability impact, which could result in users not using the system, or users taking steps to hack the system to make it easier to use, and I'm concerned that you haven't thought about the attack vectors of a social engineer. Like water, hackers will find the crack or crevice that is easiest to use.
I'm hitting you with the heavy stuff here, because my perception is you're trying to design something somewhat high end for something that is presumably high risk. If that's what you're trying to design, then you have to back up and see the whole system - your user community, birth to death of accounts, behavior within the system and the risks of bad behavior.