I've seen some password revealing software. Most of them has a shooting pointer like pointer and you can just point the password text box and the software is revealing the password.
But still the protected software and the revealer software are not interconnected. They are separate processes running on the same host.
My queries are,
How does a one process access the other software's information?
What are the limitations of it?
What are the practices that I can use for prevent this?
Edit : Yes, Keeping a password with dummy data is the mostly used solution for this. But still the same theory can be applied to some other case right? As an example an external program can read your emails, A spy program can record your activities etc. And even we can implement some cool features like drag and drop support to IE to Mozilla :)
So in this case the most effective
solution would be a "Blocking"
mechanism. Is there anyway to do this? (Avoid accessing the process's resources???)
As silky said it's just a matter of sending windows messages, there is a very simple source that reveals all password fields at once. A simple countermeasure would be a password field that holds dummy characters instead of the real password. You can capture what is being typed, store it in a variable and replace it with the dummy character in your password field.
Probably by finding the control and sending a message to the textbox that changes the 'password' character to blank (i.e. it will reeval).
So:
By sending windows messages to them
I can't recall, but I'm pretty sure you just need the window handle.
Don't display the password in a password field at all. Just hold it somewhere in memory, and only show it if the user specifically asks for it.
IIRC this "weakness" had been eliminated since about Windows XP SP2? In any case, i'm pretty sure the standard Windows textbox control that is used for passwords got an upgrade so that you couldn't just use tools like Spy++ to peek at the actual text that was being masked.
The way passwords work:
When a password is set the password is converted to a hash value using a hash function, and it is that hash value that is stored. The password is never stored. When a user logs in the password is hashed and compared to the stored hash value. If the two hashes match then the user submitted the correct password.
In order to reveal a password the stored hash value has to be compared to something with a known hash value or, in the case of a broken hash function, the hash value can be guessed into the submitted value. The later of these possibilities is the method used by Cisco password crackers, if you can get into the box, because Cisco uses a notoriously weak hash function. In the case of later Windows OSes the hash function used is NTLM, which is very strong. In this case you must compare the stored hash values to known hash values. This method is called a rainbow table. A typical alpha-numeric and 7-bit ASCII special character 14 character password has a rainbow table that is 64gb large. This is why longer passwords are vastly superior since it will take a few minutes to compare a hash value against billions of other values.
Related
I am securing our our servers using password based encryption for Jboss 5.1.0.
I have read the parts of the RFC:
https://www.rfc-editor.org/rfc/rfc2898
I have read the several Jboss documents several times:
https://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Encrypting_Data_Source_Passwords.html (this is for 6.0, but works with 5.1.0)
Now, let me explain my issue.
In the official JBoss document listed above, they treat "Secured Identity" encryption as if it is secure. Heck, it is in the documents. Worse, I've seen other people ask questions on Stack Overflow on how to use this. This is not secure. To make it secure, one has to write their own encryption class overriding org.jboss.resource.security.SecureIdentityLoginModule.
I was able to prove this by doing a quick google search of "Decrypt Jboss 5.1.0 Password" and the first result was a jar file that decrypted Jboss passwords using the recommended approach in the official Jboss documentation.
Enter Password Based Encryption.
Knowing I've already found a security flaw in the first approach, I am already wearing of taking advice from this documentation-- if your wrong once, your probably wrong twice. However, it seems I don't have I must use approach 2: Password Based Encryption.
My concern is, the documentation makes me generate a 'master.password' file. I am assuming this is the derived key function mentioned in the RFC. However, I don't know for certain.
All in all, my gut tells me this:
Your making me store a master.password on my server. The master.password file that contains the derived key function can be used by some code somewhere to simply decrypt my encrypted password. That is because I am specifying salt and iterations elsewhere in other files.
This whole process seems like a mathematical function. On my end it looks like this:
? = DerivedKeyFunction(Salt, Iterations, Password)
But for the hacker it looks like this:
EncodedPassword = DerivedKeyFunction(Salt, Iterations, ?)
I'm claim to be neither a cryptographer or a Jboss expert, but my gut tells me all a hacker needs to do is look at the Jboss source code (which is open source as far as I know) and do a little bit of reverse engineering to get the password using the server.password file.
So my question is: How secure is Password Based Encryption on Jboss (assuming the hacker gained access to the server)? Has anyone actually looked into this?
------------ EDIT -----------------
To clarify:
This is for JBoss to connect to our Database. This is not for an end-user to log into their user account on a web application.
JBoss uses a master.password (or server.password... its just a filename) which contains some sort of encrypted string. I'm not sure what's in here, its not well documented (or maybe it is and I just don't understand).
After the configuration is followed, a password is never entered again. I don't see how this is secure. I'm guessing I can somehow use the server.password file created in step 1 to decrypt my database password. Someone just hasn't written a convenient jar file yet. But the code is opensource, so I'm guessing the right person knows how to do this very easily.
I am sharing the steps due to the number of terrible setups I've seen people using on stack overflow. The steps are as follows:
From jboss/common/lib folder, Create server.password file. place in server/conf directory.:
java -cp jbosssx.jar org.jboss.security.plugins.FilePassword <8Charactersalt> <iterationsMoreThan1000> <aLongRandomPassword> server.password
#outputs server.password file which contains encrypted string.
Encrypt Database Password
java -cp jbosssx.jar org.jboss.security.plugins.PBEUtils <8Charactersalt> <iterationsMoreThan1000> <aLongRandomPassword> <databaseConnectionPassword>
#outputs encrypted DB Password
Remove Username & Password & Update Datasource XML
<security-domain>EncryptedMySqlDbRealm</security-domain>
<depends>jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword</depends>
Add Mbean To Datasource XML. it specifies the server.password file, salt and iterations.
{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/server.password
${8Charactersalt}
${iterationsMoreThan1000}
Add Application Policy To Login Config XML. specify username, encrypted password, and datasource to encrypt. There is a 1 to 1 mapping between application policies and datasources, so if you have two datasources, it appears you need 2 application policies as well. Otherwise you get errors starting up jboss.
${DatabaseUsername}
${EncryptedPassword}
jboss.jca:service=LocalTxCM,name=${DataSourceNameFromDatasourceXML}
jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword
It sounds like your just want to obfuscate your password. Encrypting it just makes this a circular process: You need to choose a password to encrypt your password that you will use to encrypt your password that you will.....
Simply Base-64 encode it. Or some other type of (non-encrypting) encoding.
First, a cavet: I know nothing of the JBoss system to which you are referring. But I'm fairly sure the system is not asking you to "store a master.password on my server." However, I am familiar enough with encryption to offer this explanation:
You want to store some plain-text data and protect it with a password. So, you ask a user for a password, encrypt it, and store the encrypted text (call this "cipher-text") and then discard the password. When the user wants to retrieve it, you ask for a password and then decrypt the "Cipher-Text". If the password is correct you will get back the original Plain-Text.
An encryption (and decryption) process requires a Key. This is numeric value, not a password. So, you need a way to derive a Key-value from some text Pass-Phrase. The DerivedKeyFunction performs this action. The returned result is not an Encoded Password. It is a Key value that is passed to the encryption/decryption process.
So, you ask the user for a Pass-Phrase, then call DerivedKeyFunction to get a Key-value, then encrypt the Plain-Text into Cipher-Text (using the Key), store the resulting Cipher-Text and then discard the Pass-Phrase and the Key.
And to decrypt, you ask for the Pass-Phrase, re-derive the Key, and then decrypt.
Basically, the DerivedKeyFunction is a Hash function (or process); you use it to "convert" the Pass-Phrase into a numeric value that can be used by the encrypt process.
Now, you will note the other two parameters to the DerivedKeyFunction: "Salt" and "Iterations". These are required to increase the difficulty of an attack on your data. "Iterations" (obviously) specifies the number of times to re-hash the Pass-Phrase. And the "Salt" injects a random number into this iterative process.
Hopefully, you see now that these are two values that you will need to store with the Cipher-Text. Any time you want to derive the Key from your Pass-Phrase, you must do it the same way each time; that means iterating the same number of times and injecting the same "Salt" value.
So, now your process is:
1) Pick a random Salt value (yes, a random number).
2) Decide on iteration count, lets say for example 100,000. (this should be a big number, so DerivedKeyFunction takes a long time; explanation in a moment)
3) Ask the user for a Pass-Phrase.
4) Call DerivedKeyFunction handing it the Pass-Phrase, the random Salt value, and 100,000. This returns a Key-value (implied by those 3 parameters).
5) Encrypt Plain-Text into Cipher-Text using the Key-value.
6) Store the Cipher-Text and the Salt value and the iteration count (100,000)
7) Discard the Pass-Phrase and Key-value.
To decrypt:
1) Ask for the Pass-Phrase.
2) Call DerivedKeyFunction handing it the Pass-Phrase, the stored Salt value, and the stored iteration count. If the Pass-Phrase is correct, then the same (correct) Key-value will be returned.
3) Decrypt the Cipher-Text into Plain-Text using the Key-value.
Ok, so why choose a large number for the iteration count? Well, an attacker is will simply just spin around trying password after password until they successfully decrypt the the Cipher-Text. But they have to call DerivedKeyFunction with each attempt they make. And, they must use the correct Salt value and Iteration count that you used when you encrypted the data. And, yes, since you had to store them for your use, an attacker will know what they are; but they still have to call DerivedKeyFunction over-and-over. So you should see that the higher you make the iteration count, the less the number of attempts-per-second an attacker can try.
Although you didn't mention it, when using CBC (Cipher-Block-Chain) type encryption algorithms, there is another parameter called the IV or Initialization Vector. This value is an input to the encryption/decryption as a companion to the Key. As it pertains to the above processes, treat it as an extension of the Key: The DerivedKeyFunction that is used should provide both a Key-value and an IV-value. And, as with the Key-value, the IV-value is never stored and is discarded at the same points that the Key-value is discarded.
Probably a super basic question. I know many online services hash and salt passwords instead of storing them as plaintext for security purposes. My university's web portal requires students to change their passwords every 6 months. From what I know, the system is built on Oracle software.
My question is, however, how does the system know when my 20 character long password (with capitals, numbers, and symbols) contains 3 characters in the same order as the new password I'm trying to set? If the passwords are hashed, shouldn't the algorithm be one-way? Or is it possible that system encrypts the plaintext passwords and stores them? Wouldn't that be less secure?
Sorry if the question is hard to understand. Let me know if you need me to clarify. Thanks in advance!
If you have to enter your previous password when creating a new one, the system can compare them directly. This could even be done client-side.
EDIT
There are only a few other possibilities
They store your password in plaintext (in which case they should fire their entire IT department)
Their encryption method is two-way i.e. it can be decrypted (in which case they should fire their entire IT department)
They temporarily store your password when you log in. Maybe in a cookie or on the server. (In which case they should fire their entire IT department)
It is likely that the prevoius password table is encrypted (possibly using rot26).
The system can only check if the new password matches the old password exactly (compares the hashes). If it's checking substring matches, the passwords are likely being stored in plaintext.
No bueno.
EDIT: Or what Nick said, of course.
My university requires you to change passwords regularly. If I try any variation on my current password I get the message:
The new password you have entered is
not acceptable for the following
reason: That password is too similar
to the old one! Please try again
please go back and try again.
Now I'm no cryptographer, but if they can compute a similarity measure between the new and old passwords, doesn't this mean that passwords are being stored insecurely, or even in plaintext?
EDIT: I may be being an idiot. They do require you to enter the current password as well.
Do you have to enter your current password when changing passwords? Perhaps they're verifying that the current password hashes to the right value, and the comparing the plaintext to the new password.
Not quite. They could take the new password you entered, change a character and check the hash of the altered password against the stored hash. Repeat this for a series of minor alterations, e.g. modifying/inserting/deleting a single character and if any of the hashes generated equal the one stored then give the error you see.
Example: Say your old password is "password" and you try change to "pssword". Insert "a" after the "p" gives you "password", which hashes to the same thing as the old password. Therefore without knowing the old password, but only the hash, we have determined that the passwords are similar.
For a password of length N, this generates and compares O(3N) = O(N) hashes. Assuming a hash takes O(N) to compute, the overall complexity will be O(N^2) which is very feasible for passwords all the way up to 1,000 characters.
There is a very rare chance of a hash collision, and the more alterations they consider similar the higher this chance. But it's still rare nonetheless.
Note that this doesn't guarantee that the passwords are being stored securely. It just means you c an't conclude that they are not being stored securely.
On Linux (and other Unix-like systems) there are two PAM authentication modules that are responsible for this:
(1) Using the remember= option for the pam_unix PAM authentication module. This stores a number of past passwords in their hashed form so that you cannot reuse an old password with no changes. A usual location for those old hashes is /etc/security/opasswd.
(2) The pam_cracklib PAM module uses the old password as you entered it in order to perform the change and checks if enough characters are different when compared to the new password you entered (see the difok= pam_cracklib option).
In no case are old passwords stored in a recoverable form...
Any semi-competent system administrator would use something similar, rather than reinvent the wheel, which probably (but not certainly) means that you should not worry.
doesn't this mean that passwords are being stored insecurely, or even in plaintext?
Could be. A pure hashing-based storage method would make it impossible to compare for similarity: Only perfectly identical passwords could be found out that way.
They could be using an algorithm like SOUNDEX to check similarity - that wouldn't be as awful a practice as storing plaintext passwords, but still a terrible thing to do.
But of course, it's possible that the passwords are stored as plain text. You'd have to ask.
A hypothetical situation: you've implemented a password handling system, and it doesn't impose any limitations at all on what characters can be used. You want to set up some rules that are a reasonable compromise between two things -
Allow the user as much freedom as possible.
Allow for the possibility that you may change how you handle passwords in the future - you don't want to rule out reasonable implementations because your users' existing passwords would become invalid.
What rules would you impose? Are there other factors that might affect you choice?
Do not impose no restrictions whatsoever, ever. And it seems to me that you're planning on storing password, not hash. Do not do that either. Rather, store salt and hashed combination of password and said salt.
However, you can require your users to have a reasonably strong password by imposing restriction on length (say, not less than 6 characters) and on characters which comprise the password (say, it should contain lower- and uppercase alphabetic characters, one or two digits and several non-alphabetic characters such as ^ or #).
Best is no restrictions whatsoever, unless you can really justify them.
If you are a bank, email provider, or if the user can order something without supplying a credit card, then forcing users to use a strong password makes sense. Otherwise, you're just making it hard for no reason.
As to what you should store, I'd say 1024 characters of unicode with control characters prohibited is about all that's justified. If the user can't type it, they should have picked a different password. All you're storing is a hash, so you can always cut it down to whatever size you want.
No limit on the password. If they can type it from their keyboard, regardless of what regional keyboard they use. You may want to impose a minimum length, options like at least one number and one special character, but no max limit.
Regarding your second question. The way I would implement it is via making seperate fields as you improve password strength. For example, right now you would have two fields that relate to the password: salt, password_md5. Lets say later on you want to use sha256. Create a new field called password_sha256. When the user logs in you first check password_sha256. If that field is empty then check password_md5. If that matches you now have the plain text password the user entered. You can then generate the sha256 password (I'd also reset the salt for good measure) and store the new value. I would then blank out the value in password_md5 so no one could reverse that to get the password.
Personally I'd just go with the best hash your language can do and use that. The important things are enforcing a good minimum password policy--it doesn't matter how secure the hash is when the password is "1234"--and to seed the hash with some random character to avoid dictionary attacks.
Any non-control character should be fine. I should think that the developers of super-duper password systems in the future would allow "unusual" ASCII characters like punctuation and other marks, but control characters have a habit of being unwieldy to enter in text mode shells and even GUI dialogs that expect Tab and Enter/Return to be free for their own purposes.
A blank space (based on the logic it may be trimmed accidentally before being hashed)
Personally I have always been keen on not enforcing too many rules.
This has just changed. I have just found my website is vulnerable to XSS attacks. The solution is to sanitise every piece of input that comes from the user, including the password.
For 10 years we have had no limits on the password.
Now we are implementing a limit to the characters that can be used, and this is simply to block hackers from being able to access Javascript or SQL. So we constructed the following list:
Valid characters for a password are: a-z A-Z 0-9 . - _ $ * ( ) # # ! % / (blank)
This allows lots of flexibility but avoids characters that might be used in coding an XSS hack, such as ; < > \ { } [ ] + = ? & , : ' " `
HTH
In our organization, if the user is supplying the password we allow them to use anything they want.
When users are first enrolled in the system a password is generated for them. Since this password is usually mailed to them, we avoid using certain characters that could be confused particularly when using certain fonts. For example, the letter O and the number 0 (zero) are not used. The same for L, I and 1 (one), S and 5, Z and 2 and others.
Before we made this change we had a lot of calls to our help desk because the characters were confusing and they couldn't log in.
I'd keep anything you can make with one key (and optionally shift) on your keyboard, except tab. What kind of schemes would necessitate a more restrictive option?
Have the users type passwords that contain at least a number and a non-alphanumeric character, and be more than six characters long. Anyway, I think that whatever the limitations, in the event that you change the way you validate passwords, you should notify users in reasonable time to update theirs.
Personally, I use DigitalPersona's Fingerprint Keyboard (yes, Microsoft does [or did] make a similar device, both integrated with or separate from the keyboard).
This allows the generation of extremely long and complicated passwords that don't have to be written down (as the press of your finger on the reader supplies the password to the Logon dialog [system/application/website]).
This, in my opinion, provides the best of both worlds: Extremely difficult to "guess" passwords, without having to remember them. It also makes simple the additional security recommendation of using different passwords on different systems.
Well, that's my two-cents' worth.
Some rules to follow:
Avoid Control Characters. It's not as prevalent today, but control characters all have special meanings and some hardware intercepts control characters to perform special functions. Some will cause data issues Example Control 0 (Zero) would generate a null.
Are you going to impose security restrictions? This is a user interface question as well as a security issue. What is your application and it's need for security. Many of the examples previously given are out of date. Hash tables for combinations of passwords are published for up to 15 character passwords and 16 character passwords can be brute forced withing minutes if the password is otherwise weak or follows typical human behavior. Starts with a capital, ends with number or special character.
I'd avoid common wildcard characters, quotes, colon, semi-colon, etc... that are commonly used in OS or DB languages.
Multi-factor authentication is a good way to go. Don't depend upon the password only or don't accept passwords at all.
I've been asked to implement some changes/updates to an intranet-site; make it 'future proof' as they call it.
We found that the passwords are hashed using the MD5 algorithm. (the system has been around since 2001 so it was adequate at time).
We would now like to upgrade the hashing-algorithm to a stronger one (BCrypt-hash or SHA-256).
We obviously do not know the plaintext-passwords and creating a new password for the userbase is not an option*).
So, my question is:
What is the accepted way to change hashing-algorithm without having access to the plaintext passwords?
The best solution would be a solution that is entirely 'behind the scenes'.
*) we tried; tried to convince them, we used the argument of 'password age', tried to bribe them with coffee, tried to bribe them with cake, etc. etc. But it is not an option.
Update
I was hoping for some sort of automagic solution for solving the problem, but apparently there are no other options than just 'wait for the user to log in, then convert'.
Well, at least now I now there is no other solution available.
First, add a field to the DB to identify whether or not the password is using MD5 or the new algorithm.
For all passwords still using MD5:
-- In the login process, where you verify a user's entered password: temporarily store the user's submitted password in memory (no security issue here, as it is already in memory somewhere) and do the usual MD5 hash & compare with the stored hash;
-- If the correct password was given (matches the existing hash), run the temporarily stored password through the new algorithm, store that value, update the new field to identify that this password has been updated to the new algorithm.
(Of course you would just use the new algorithm for any new users/new passwords.)
I'm not entirely sure about this option, since I'm not an expert on cryptography. Please correct me if I'm wrong at some point here!
I think Dave P. has clearly the best option.
... but. There is an automagic solution - hash the older hashes themselves. That is, take the current hashes, and hash them again with a stronger algorithm. Notice that as far as I understand, you don't get any added security from hash length here, only the added cryptographical complexity of the new algorithm.
The problem is, of course, that checking a password would then have to go through both hashes. And you'd have to do the same for evey new password as well. Which is, well, pretty much silly. Unless you want to use a similar scheme like Dave P. explained to eventually graduate back to single-hashed passwords with the new hashing algorithm... in which case, why even bother with this? (Granted, you might use it in a flashy "Improved security for all passwords, applied immediately!"-way at a presentation to corporate suits, with a relatively straight face...)
Still, it's an option that can be applied immediately to all current passwords, without any gradual migration phase.
But boy, oh boy, is someone going to have a good laugh looking at that code later on! :)
Add passwordChange datetime field to the database.
All password set before day X, check using MD5
All passwords set after day X, check using BCrypt or whatever.
You could store, either in the hash field itself (e.g. "MD5:d41d8cd98f00b204e9800998ecf8427e") or in another column, which algorithm was used to create that hash. Then you'd have to modify the login process to use the correct algorithm when checking the password. Naturally, any new passwords will be hashed using the new algorithm. Hopefully, passwords eventually expire, and over time all of the MD5 hashes will be phased out.
Since you don't know plaintext password, maybe you should to create a field which indicates encription version (like PasswordVersion bit default 0)
Next time user tries to log in, check hashed password using current algorithm version, just like you do today. If it matches, hash it again and update PasswordVersion field.
Hopefully you'll not need a PasswordVersion column bigger than bit. =)
You should change your password database to store 3 items:
An algorithm identifier.
A random salt string chosen by the server when it first computes and stores the password hash.
The hash of the concatenation of salt+password using the specified algorithm.
Of course these could just be stored together in one text field with a delimiter:
"SHA256:this-is-salt:this-is-hash-value"
Now convert you existing entries to a value with empty salt and the old algorithm
"MD5::this-is-the-old-md5-hash-without-salt"
Now you have enough information to verify all you existing password entries, but you can also verify new entries (since you know which hash function was used). You can convert the old entries to the new algorithm the next time the existing users login since you will have their password available during this process:
If your database indicates they are using the old algorithm with no salt, first verify the password the old way by checking that the MD5 hash of the password matches. If not, reject the login.
If the password was verified, have the server choose a random salt string, compute the SHA256 hash of the salt+password, and replace the password table entry with a new one specifiy the new algorithm, salt and hash.
When the user logs in again, you'll see they are using the new algorithm, so compute the hash of the salt+password and check that it matches the stored hash.
Eventually, after this system has been running for a suitable time, you can disable accounts that haven't been converted (if desired).
The addition of a random salt string unique to each entry makes this scheme much more resistent to dictionary attacks using rainbow tables.
The best answer is from an actual cryptography expert
https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#legacy-hashes
This post also helps explain which hashing you should use. It's still current even if it says 2016. If in doubt use bcrypt.
Add a column to your user accounts table, called legacy_password (or equivalent). This is just a Boolean
Calculate the new stronger hash of the existing password hashes and store them in the database.
Modify your authentication code to handle the legacy flag.
When a user attempts to login, first check if the legacy_password flag is set. If it is, first pre-hash their password with your old password hashing algorithm, then use this prehashed value in place of their password. Afterwards (md5), recalculate the new hash and store the new hash in the database, disabling the legacy_password flag in the process.