I don't believe that's possible. You could have two entries in /etc/passwd with the same user names but different UIDs, but the system would probably just ignore the second one (or misbehave in some way); arguably such an /etc/passwd file would be considered corrupt.
When you login to the system, you're first prompted for your user name. Once you've done that, the system prompts for your password, and checks whether the entered password matches the password for the account corresponding to that user name. By the time you're entering your password, the system has already determined what account you're trying to access.
I suppose you could modify various pieces of the system to get the behavior you want, but you'd have to replace several different pieces of software, including anything that authenticates and authorizes users (console login, su, ssh, and whatever other methods are enabled). Any mistakes would likely open huge gaping security holes.
EDIT : Based on the comments, PAM is probably the way to do this. I'm not familiar enough with PAM to go into more detail. (It's still a really bad idea.)
I have seen that application do that as well. I think it is a result of the bash script (that is the pass program) not catching some errors. For me it was reason not to start using the program for real.
If you can live with the plain text files being stored locally, you can prevent them from being stored in git (and pushed out to github) by setting up a .gitignore file in your ~/.password-store:
*
!*/
!.gitignore
!.gpg-id
!*.gpg
(this first ignores everything to be stored, then allows subdirs and allows the configuration files as well as all files ending in .gpg).
If you haven't done so yet, you should immediately change all passwords that you pushed out to github. Also remove ~/password-store/.git and everything underneath and reinitialize git (pass git init) for the password store, as the old, committed, plaintext files will still be in there.
Best Answer
For the early history of Unix password storage, read Robert Morris and Ken Thompson's Password Security: A Case History. They explain why and how early Unix systems acquired most the features that are still seen today as the important features of password storage (but done better).
cryptfunction which hashes the password. It's described as “encryption” rather than “hashing” because modern cryptographic terminology wasn't established yet and it used an encryption algorithm, albeit in an unconventional way. Rather than encrypt the password with a key, which would be trivial to undo when you have the key (which would have to be stored on the system), they use the password as the key.Originally the password hash was in the publicly-readable file
/etc/passwd. Putting the hash in a separate file/etc/shadowthat only the system (and the system administrator) could access was one of the many innovations to come from Sun, dating from around SunOS 4 in the mid-1980s. It spread out gradually to other Unix variants (partly via the third party shadow suite whose descendent is still used on Linux today) and wasn't available everywhere until the mid-1990s or so.Over the years, there have been improvements to the hashing algorithm. The biggest jump was Poul-Henning Kamp's MD5-based algorithm in 1994, which replaced the DES-based algorithm by one with a better design. It removed the limitation to 8 password characters and 2 salt characters and had increased slowness. See IEEE's Developing with open source software, Jan–Feb. 2004, p. 7–8. The SHA-2-based algorithms that are the de facto standard today are based on the same principle, but with slightly better internal design and, most importantly, a configurable slowness factor.