How would I need to alter the kernel to do the following.
Login:User
Password:<enter passwd 1>
Password incorrect
Password:<enter passwd 2>
Password incorrect
Password:<enter passwd 3>
User is logged in
The examples shows the user using 3 passwords sequentially (the first to returning incorrect) to login.
The simplest approach would be to write a PAM which asked for multiple passwords. No need to touch the kernel.
I suggest asking three questions per login would be cleaner than trying to maintain state of how many previously-correct passwords were entered. Otherwise you have potential interactions where logins happen concurrently or tools attempt to login using a saved (last) password... also lockout policy would need consideration in the face of right-but-wrong passwords. You would also have to ensure that the module gave no external sign of part-passwords being correct.
Three passwords is logically equivalent to one long password, with the additional element of a measure of obscurity. It might be simpler to strengthen password length/complexity requirements.
Related
There are many operating system and programs that hash passwords for authentication.
Even though they can encrypt the password in many different ways and save it
why do they save the hash of them?
Is the only reason to that question that encrypting them may cause in breaking and decrypting them or there are other reasons?
Thanks for answering in advance
User credentials (≈passwords) are among the most valuable assets stored in an application. They are a prime target for attackers, and as a developer, you want to protect them the best you can.
The principle of defense in depth (and common sense) indicates that the more layers of protection you can put around something, the more secure it will be. So as you also mentioned, the purpose of hashing passwords is that even if there is a breach, an attacker still can't get hold of actual user credentials.
The problem with encryption is always key management. If passwords were stored encrypted, they would need to be decrypted (or the received password encrypted with the same key) to be able to verify a password. For this, the application would need to have access to the key. But that negates the purpose of encryption, an attacker would also have access to the key in case of a breach. (Public key cryptography could make it somewhat more difficult, but essentially the same problem of key management would still persist.)
So in short, only storing salted hashes with an algorithm that is slow enough to prevent brute-force attacks (like PBKDF2 or Bcrypt) is both the simplest and the most secure. (Also note that plain salted hashes are not good enough anymore.)
Think of the need: You define your new password, and then every time you log-in the entered password is hashed and checked against the stored value. This is the simplest and most secure policy to handle this (since no one will be able to re-construct your password from the stored value). Moreover, imagine that you use the same password in several systems. If Windows would enable (regardless how hard it would be) to re-construct your password from what is stored in a Windows system, there would be (quite many) people that would blame Microsoft for security breach on other system (which could derivate into legal actions).
To summarize, simplicity and commercially logical approach.
Well, actually it's for security reason.
Hash functions are usually not revertibles, so even if someone finds out the hashes it would be really difficult for him to find which password generated that hash value.
Obviously you can try with a dictionary attack or a brute force one, trying to find out the password which generated the hash but it could take a very long time.
Consider that you have a Database with user and their passowrd, take note that a lot of people use the very same password everywhere.
Now immagine if a cracker manages to crack into your DB and finds all the password written clearly. That would be a disaster.
I'm writing an application to protect passwords from key sniffers and screen retrievers. I have the user type in an easy-to-remember keyword or phrase (i.e, "password123", "amazon.com", "gmail") and I use that string to create a longer and stronger password which is loaded into the clipboard. I want the application to be completely anonymous, so I don't save any information. To generate the passwords, I use a random number generator. I need a way for the user to carry around their seed that isn't vulnerable to key sniffers or screen retrievers. I'm thinking a hardware token like a YubiKey, but I would like something more easier and more mainstream. I tried using behavioral biometrics, but I managed to replicate them with a program too easily. Any better ideas?
What you are suggesting is a more than vulnerable approach.
First of all, there are open source and proven-correct algorithms and applications for the problem you are targeting. In security questions it is never a good idea to go and develop applications for critical operations (and handling passwords is always a critical operation) on your own, especially reinventing the wheel is almost in every case an endeavor doomed to fail.
Your approach is problematic in several points:
To be anonymous the app needs to copy/paste or in-place-generate the password needed for some action. You will have a hard time avoiding screen retrievers capture that if you do not do some magic on OS level.
Using one(!) random seed to protect several passwords makes each of them weaker than it was before.
Carrying this random seed on a usb key and freely plugging it into all kinds of computers that you cannot control is a problem as each of them may be potentially malicious. The random seed could be silently retrieved, altered or deleted.
To give you some things to get paranoid about, google e.g. blue pill and you will see that the real problems dwell on another machine layer than the application you are talking about.
Instead have a look at the following approaches:
2 factor authentication (2FA) against malicious software and hardware stealing your passwords on type-in. See e.g. Google Authenticator.
Secure operating systems against such software entering your system and retrieving your passwords. See e.g. QubesOS
Read-only drives with secure / anonymous OS for usage on foreign and potentially dangerous machines even for very critical tasks such as banking. See e.g. Tails OS on a dvd (not a usb key!)
Virtual machines to capsule potentially malicious tasks. See e.g. VirtualBox
Trustable password safes like KeyPassX
In a nutshell: You can write such an application but it will most likely not be practical nor secure nor by so usable. Sorry about that.
To start, I am trying to encrypt very sensitive information on a public website. Users will be able to update their information, Administrators will need access to this information. I am worried that if the encrypted data is some how compromised, then everyone's information would be as well due to them all using the same salt and key.
So I know using a salt, and key is always preferred. But as mentioned above if they reverse engineer the encrypted data, what use it is.
My solution, is to have the key and salt stored in a DB, with many rows and columns, any of which can be used for the salt or key. I would have an algorithm that will use "something" fixed in the users account that will be used to figure out which salt and key to use. This way statistically speaking no 2 years will have same combo of salt and key.
Is this over kill, or good?
I question the value of this second database that holds keys and salts. Consider:
The "something" in the user's data that identifies the salt and key will necessarily have to be encrypted differently from the rest of the user's data. Otherwise, you wouldn't be able to get it without first already having it.
Statistical analysis of the encrypted user data would almost certainly discover that the "something" is encrypted differently. That will be like waving a red flag at a bull, and an attacker will concentrate on figuring out why that's different.
You can assume that if an attacker can get the database of encrypted user information, he can also get the database of salts and keys.
Given that, there are two possible scenarios:
The encryption of the "something" that identifies the key and salt is unbreakable. That is, it's so good that the attacker's best efforts fail to reveal the connection between that "something" and the key/salt database.
The attacker discovers the encryption of the "something," and therefore is able to decrypt your sensitive data.
If #1 is the case, then you probably should use that encryption algorithm for all of your user data. Why do something in two steps when you can do it just as effectively in one?
If #2 is the case, then all the work you've done just put up a little bump in the road for the attacker.
So, short answer: what you propose looks like either unnecessary work or ineffective road blocking. In either case, it looks to me like a whole lot of work and added complexity for no appreciable gain.
That said, I could have misinterpreted your brief description. If so, please correct me.
My concern is that after I login using the Auth->login() method, all the data regarding the User is stored in session but NOT the password. I wonder is it normal? and how can I specifically choose what fields I want to store in session when logging in.
Restating what I said in comments: storing passwords in sessions is not safe at all, and there should be no reason to do it.
Really, don't do it. Don't.
Let's enter in fantasy world. If the Auth component saves the password in session, it has two possibilities to do so: save it as plaintext, or save it hashed and salted.
Scenario one:
It would be the same as writing your password in your forehead, take a selfie, and post it on facebook (or the next new social network). Anyone that sees your session (it can be done) will have your plaintext password. And if the user uses the same password for everything... yay free amazon shopping!!
Scenario two:
it is "safer" in a way that is not plaintext. But the safest thing? Not giving anyone the least bit of info about the password. Is easier to decrypt something if you know the final product. Meaning by brute force, if I know a plain password "12345" is hashed and salted and produces "i8g04", and I have the same thing for a lot of other users, eventually I'll be able to deduce what salt you used and how to hash it. "Eventually" maybe meaning instead of 2^58 is 2^57 tries by brute force. That's a lot less time and processing (1.4411519e+17 according to google). So... nah, better not to do it. And for what would you (or cake) use that hashed-salted password for?
and how can I specifically choose what fields I want to store in session when logging in
I don't know a way to do it, there's just one optional parameter in login, so no options there... you could extend the Auth component to add the functionality if you want... But if you want to do this for something specific, maybe you'd be better off explaining your reasons to us and we could give you advice on how to do it.
PD: I repeat, don't store passwords in session.
SecOps people disclaimer: I'm an informed amateur at this stuff. It's possible I'm misunderstanding something. If so, please advise :)
I'm doing some work with the Keychain/KeychainItemWrapper in my app. I want to store a user's password in a secure manner, and the Keychain seems like the way to do it.
However, I'm a little confused. I thought basic password security (modelled after unix crypt()) went something like this:
Encrypt and store user specified password, using an encryption algorithm that will give the same results every time (given the same salt)
At a later date, when the user enters their password, encrypt that too
Compare the two encrypted strings. Are they equal? The passwords must be the same
However, it appears that using KeychainItemWrapper (and maybe the entire Keychain API?) is meant towards giving the password as plain text back to the program. However, isn't that insecure? The unencrypted password is just sitting around in memory, waiting for someone to read it, right?
The question: What is the best pattern for storing passwords in Keychain, given my above worries about security and the fact that my program does not actually need to know the encrypted value? Or are my fears unfounded and I should stop worrying and learn to love the (unencrypted) password Keychain gives me?
You're confusing two concepts (hashing vs encryption).
When you need to verify that someone knows a password, you hash it (w/ salt) and store that hash. Then, when someone tries to authenticate as that user, you ask them for the password, hash it with the same salt, and compare with the stored value. This is ideal as hashing is a one-way/non-reversible function. So, if someone accesses your credential store, they gain nothing as they would need to crack that hash (and modern algorithms like crypt/bcrypt are specifically designed to make brute force cracking very difficult).
However, if you need to be able to actually recover the plaintext password, you will encrypt the password instead of hashing it. Unlike cryptographic hashing, encryption is reversible, assuming you know the key.
The Keychain encrypts whatever you store in it with the assumption that you'll need to recover the actual data at some point (for example, if I put my Facebook password in a Keychain, it would be able to decrypt it and supply the actual password, when I need to use it to access Facebook). Keychain is designed to store those secret values encrypted, so that when you need to actually recover the original value you can.