I am presently focusing on fundamental user authentication to have an application I am assembling, and that i do not have much knowledge about security.

This stated, I realize the practice (and necessity) of salting/storing a (salted) password hash inside a database like a blob, instead of the password (encoded or no). I have already implemented this.

Can there be almost anything to be acquired by salting/hashing a person title and storing the hash within the database, instead of the username in plain-text (or encoded)? It strikes me this could allow it to be a great deal harder to find out which customers may access the machine while using database for authentication.

Becasue it is vital to really make it hard for anyone to crack the password for any user account, would it not also seem sensible to improve the problem for identifying which customers are viable?

Edit: it is possible a few of the language I am using is not 100% correct: you can correct :-)

Edit2: I transformed among my first indicates indicate salting hashes -- thanks everybody for mentioning which i skipped this :-)

Edit3: Removed wording showing I'm encrypting/decrypting your password. I am using salted hashes and am storing that within the DB -- thanks Scotty for pointing this out.

Should you salted &lifier hashed the username, you'd leave yourself with a little of the chicken &lifier egg problem.

Should you salted &lifier hashed the username, how does one think it is within the database? You'd may need to look in the user's record to obtain the salt you accustomed to hash the username...

Short answer: probably no.

Lengthy answer: Your circumstances appears to don't have the key "my usernames are sensitive due to ..." which boosts the question: "Why? What's the specific, demonstrable problem that safeguarding usernames would solve?"

Without this problem, what you're explaining is a very common pitfall in security-related development (and extremely development in general): approaching with a few idea to secure or obfuscate some area of the system, after which hunting for a reason for doing things. Just like anything in software development, you need to avoid doing anything apart from what is needed until a obvious problem comes up that may simply be solved using a specific tool.

Extra hint (free of charge!): salt your password hashes. Plain-old hashes are far less secure.

Most likely not. Think about it by doing this - the username may be the application's method of determining which account a person is attempting to login as. The password may be the application's method of determining if the user is really permitted to login as that account. Used, what this means is you are going to find information about a row inside your accounts table while using username being an index. By encrypting the username, you are simply which makes it harder to obtain the right row.

However, if you are utilizing the same file encryption plan to secure the account information, they're virtually equally secure - if you're able to break one, you are able to break another. Thus, encrypting both causes it to be harder to research the consumer, but does not add any extra security.

Note: Inside your question you discuss decrypting passwords area. You most likely need to make this impossible (literally). Many people secure their passwords utilizing a one-way hash purpose of some kind (MD5 and SHA256 are popular), together with a salt. The "one-way" part only denotes that when you take something with the function, you cannot use what you'll get to get that which you began with. However, if starting with exactly the same input, you'll always obtain the same output. The salt is really a secret that only the application knows (kind of as an file encryption key), that is put into anything you are encrypting, prior to it being tell you the main one-way hash. This causes it to be out of the question such things as match two encoded passwords from two different sites (presuming they are using different salts).