Tag Info

New answers tagged

-1

I think there's a fundamental flaw in the question. The fact is, there's no such thing as a "secure database". It should be taken as a given that there are flaws in your system somewhere that could allow malicious users access to arbitrary data on your servers. Heartbleed is an excellent case in point, being an exploit that was in the wild for over two years ...


2

It's not "common sense" not to store credentials in source control. That really depends on your situation. It's a perfectly acceptable practice if the developers would already have access to production resources, or if the accounts are read-only and there's no privacy issue, or if the credentials are encrypted in some way. If you're going as far as building ...


0

I found good ideas here such as: Encrypting/decrypting data (see nice and detailed post here by John Resig) Using a separate configuration data repository


1

risks for SQL injection everywhere That's your chance. Exploit this and show your boss, how easy it is for any stranger to read the whole database, including your boss's password. Then ask him, on how many web sites he personally uses the same password. After he answered this, it's time to explain, what salted hashes in your web app can do for his ...


-1

If you're dead set on being able to recover "the" password, I'd be tempted to try and give your users a tiny amount of security by hashing the passwords in such a way as to make it trivial to create a password that hashes to the same value without necessarily being the same password. (Remember, a high percentage of your users will be using the same password ...


14

Yes. Always generate a new salt when the password is changed. Consider the following two scenarios: Known not changing salt I know you aren't changing the salt for your passwords. I see admin has a salt that is 'xyz', and now I grind out the rainbow table for that salt. Doesn't matter what you change your admin password to, I know it. Repeated ...


0

If you are set on doing this, the ideal solution seems to me to use a Bloom filter of the known "bad passwords". The advantage is that even in a compromise, you only leak information about the passwords of known/suspected bad actors, and you never directly leak any password hashes. In addition, a dense Bloom filter is very fast to search and can be sized ...



Top 50 recent answers are included