I want to say don't use SSNs like usernames for practical and ethical reasons. Yet I hope that if you switch to normal username/passwords you won't remove the (weak) password protection on encrypted SSNs that you already have. There also may be legal requirements surround SSN storage, but I know nothing about that. Definitely don't use SSNs because you believe in inflicting some "real name" philosophy on users. If you're doing something like filling out forms for a person then consider only storing the SSN client side even if it means they have to type it in multiple times.
If you really must do something like what you describe and can't add a username then store the hash of the pair (SSN, password). To check if a person's password is correct check for set membership of $H(SSN, Password)$ in a hash table*. No need to store (H(SSN), H(password)) like something you might be thinking. You then can replace the SSN ciphertext with the SSN+Password hash. This has the downside that you don't have a pure software way to prevent multiple sign ups. Which may not be a problem if sign up involves paper forms and manual account activation.
I can't think of a way to use salt if you're using SSNS like a username that has to be secret. Normally you use non-secret information to look up salts. You have similar problems as you would have if you used only a password in place of a username+password combo. (Perhaps minus password collision problems). Adding username or email would let you add salt.
You will want to consider where you allow yourself to use the SSN. Client side only? In RAM only? RAM and hard drive? RAM and SSD? Can the SSN end up getting written to swap space? Is hibernate disabled? Will crash dumps contain secrets? Logs?
(Unfortunately I don't know that real world companies really put any thought into these questions.)
Also consider: A person's assigned SSN can be changed. The person assigned to one SSN can change.
* Try to be aware of implementation details. Databases may leak some information. Deleted rows might not actually result in data getting cleared for example. There could be forensicly interesting information in the disk representation of a database as well. (As opposed to history independent data structures.)