Might be a dumb question
-
I was perusing the daily WTF and found this: http://thedailywtf.com/forums/thread/98876.aspx[^] One of the rules for the password was that it contain exactly 8 characters. From a user's perspective this sounds like a really stupid rule. But what I was wondering was if the system uses a block cipher, then they'd have to store the length of the password along with the encrypted password. That's so they can remove the garbage that is left over when decrypting. Is this some kind of common practice to get around having to store the password length or is there something else that would require a password to be an exact number of characters? Or is it just a WTF? Do any of you cryptography gurus have some insight on this?
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family."The whole idea of using block ciphers for storing passwords these days is a big WTF. The smart choice is to use one way hash functions. The stored password hash H is calculated by applying the hash function F on the user's password P concatenated with his username U:
H = F(P || U). When the user wants to authenticate himself later, a hash H' is calculated on the user supplied credentials (P' and U'):H' = F(P' || U'). IfH = H', then it is very likely (error probability being one in zillion billions raised to the power of zillions - or something like that, depending greatly on the hash algorithm) that the user is who he claims to be (or at the very least knows the user's password). The reason why the hash is calculated on password and username is simple. If it wasn't, it would be easy to compare people's hashed passwords and see if they are using the same password. Such weaknesses could help in an attack.-- Broadcast simultaneously one year in the future
-
Dustin Metzgar wrote:
Is this some kind of common practice to get around having to store the password length or is there something else that would require a password to be an exact number of characters?
I believe this is because of a flaw in Triple DES. For some reason when you had a long password, their was actually a "leak" of bits into the encoded portion of code. The longer the password, the more bits leaked, so to avoid leaking too many bits, you wanted to keep your password to a min&max of 64bits (actually 56bits because it only used 7bits per byte, but hey, I will try not to nit-pick). As far as I know as long as you are not using DES or triple DES, the length of the password is irrelevant. If you are using triple DES then you want to make sure you use 8 bytes of an ASCII password, or a binary SALT that masks all the leaking bits.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
A triple DES block is 64 bits, so if your password is greater than 8 characters, then it would have to do more than one block. If there are several blocks that are identical, then you know that a certain character string was repeated, which could help you in determining the plaintext. But it seems to me that this shouldn't be a problem with passwords. If you just want to fill up 64 bits, saying that your password should be a length that is a multiple of 8 is more of a WTF than saying it should be exactly 8. But is there some problem with padding a password with 0'd bits to fill the 64 bit blocks? BTW, I'm also of the opinion that hashes are far better, but I'm curious about this. :)
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family." -
The whole idea of using block ciphers for storing passwords these days is a big WTF. The smart choice is to use one way hash functions. The stored password hash H is calculated by applying the hash function F on the user's password P concatenated with his username U:
H = F(P || U). When the user wants to authenticate himself later, a hash H' is calculated on the user supplied credentials (P' and U'):H' = F(P' || U'). IfH = H', then it is very likely (error probability being one in zillion billions raised to the power of zillions - or something like that, depending greatly on the hash algorithm) that the user is who he claims to be (or at the very least knows the user's password). The reason why the hash is calculated on password and username is simple. If it wasn't, it would be easy to compare people's hashed passwords and see if they are using the same password. Such weaknesses could help in an attack.-- Broadcast simultaneously one year in the future
-
Dustin Metzgar wrote:
Is this some kind of common practice to get around having to store the password length or is there something else that would require a password to be an exact number of characters?
I believe this is because of a flaw in Triple DES. For some reason when you had a long password, their was actually a "leak" of bits into the encoded portion of code. The longer the password, the more bits leaked, so to avoid leaking too many bits, you wanted to keep your password to a min&max of 64bits (actually 56bits because it only used 7bits per byte, but hey, I will try not to nit-pick). As far as I know as long as you are not using DES or triple DES, the length of the password is irrelevant. If you are using triple DES then you want to make sure you use 8 bytes of an ASCII password, or a binary SALT that masks all the leaking bits.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
I believe this is because of a flaw in Triple DES. For some reason when you had a long password, their was actually a "leak" of bits into the encoded portion of code.
do you have a cite for this?
-
I was perusing the daily WTF and found this: http://thedailywtf.com/forums/thread/98876.aspx[^] One of the rules for the password was that it contain exactly 8 characters. From a user's perspective this sounds like a really stupid rule. But what I was wondering was if the system uses a block cipher, then they'd have to store the length of the password along with the encrypted password. That's so they can remove the garbage that is left over when decrypting. Is this some kind of common practice to get around having to store the password length or is there something else that would require a password to be an exact number of characters? Or is it just a WTF? Do any of you cryptography gurus have some insight on this?
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family."typically, you just pad the data out to the block length. maybe the person who designed it didn't know about the various data padding schemes, but knew he had to give the cipher 8 bytes of data because that's what the
encrypt(data, key)function documentation said. -
The whole idea of using block ciphers for storing passwords these days is a big WTF. The smart choice is to use one way hash functions. The stored password hash H is calculated by applying the hash function F on the user's password P concatenated with his username U:
H = F(P || U). When the user wants to authenticate himself later, a hash H' is calculated on the user supplied credentials (P' and U'):H' = F(P' || U'). IfH = H', then it is very likely (error probability being one in zillion billions raised to the power of zillions - or something like that, depending greatly on the hash algorithm) that the user is who he claims to be (or at the very least knows the user's password). The reason why the hash is calculated on password and username is simple. If it wasn't, it would be easy to compare people's hashed passwords and see if they are using the same password. Such weaknesses could help in an attack.-- Broadcast simultaneously one year in the future
Total FUD, complete bunk. Clearly you must be a younger programmer - anyone who know *anything* knows that you just compress the password using pkzip to a singly byte and OR 0x32 to it. Then just send the byte around. Saves space and it's efficient. Pfft, one ways hashs, I mean COME ON Joergen, that's so 20th century.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Techno Silliness
-
The whole idea of using block ciphers for storing passwords these days is a big WTF. The smart choice is to use one way hash functions. The stored password hash H is calculated by applying the hash function F on the user's password P concatenated with his username U:
H = F(P || U). When the user wants to authenticate himself later, a hash H' is calculated on the user supplied credentials (P' and U'):H' = F(P' || U'). IfH = H', then it is very likely (error probability being one in zillion billions raised to the power of zillions - or something like that, depending greatly on the hash algorithm) that the user is who he claims to be (or at the very least knows the user's password). The reason why the hash is calculated on password and username is simple. If it wasn't, it would be easy to compare people's hashed passwords and see if they are using the same password. Such weaknesses could help in an attack.-- Broadcast simultaneously one year in the future
That's what I thought - but everytime I try to find a good function, google returns elaborate garbage.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify! || Fold With Us! || sighist -
Using one way hash is also very effective to authenticate across systems, I use it for credit card merchants and applications that are linked but not under the same server.
They use digital signatures to verify authenticity (assymetric ciphers such as RSA in combination with hash functions). The hash by itself is only used to verify data integrity.
-- Transmitido en Martian en SAP
-
Total FUD, complete bunk. Clearly you must be a younger programmer - anyone who know *anything* knows that you just compress the password using pkzip to a singly byte and OR 0x32 to it. Then just send the byte around. Saves space and it's efficient. Pfft, one ways hashs, I mean COME ON Joergen, that's so 20th century.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Techno Silliness
Jim Crafton wrote:
Pfft, one ways hashs, I mean COME ON Joergen, that's so 20th century.
Sorry. I meant to say hashish functions. :rolleyes:
-- Painstakingly Drawn Before a Live Audience
-
Jeffry J. Brickley wrote:
I believe this is because of a flaw in Triple DES. For some reason when you had a long password, their was actually a "leak" of bits into the encoded portion of code.
do you have a cite for this?
Chris Losinger wrote:
do you have a cite for this?
Not the details, but quite a few links on known DES vulnerabilities are on the net. A change in procedure for DES was introduced in Kerberos 5 support to get around the leaked bits into the stream that was even known back in version 4. A flaw that allowed only capture of a triple DES or DES stream to eventually lead to enough information for decription. If you recall there was a massive call to upgrade all kerberos systems a couple years back. As far as I know this has been handled procedurally. http://www.kb.cert.org/vuls/id/442569[^] DES and Triple DES are 8 byte key (56bits) and 8/8/8 byte key (168). By getting around the flaw of leaked bits, if I recall the current true bit complexity (non-leaked) is at around 128bit on triple DES which is still pretty decent.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
typically, you just pad the data out to the block length. maybe the person who designed it didn't know about the various data padding schemes, but knew he had to give the cipher 8 bytes of data because that's what the
encrypt(data, key)function documentation said.Chris Losinger wrote:
typically, you just pad the data out to the block length.
true, and often the system uses a salting method to either increase, or decrease the bytes of the password to 8 bytes (56 or 64bits) for block encrypting. The question comes in whether or not that salting procedure accidentally decreases the bit complexity of the 8 byte block cypher key.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
A triple DES block is 64 bits, so if your password is greater than 8 characters, then it would have to do more than one block. If there are several blocks that are identical, then you know that a certain character string was repeated, which could help you in determining the plaintext. But it seems to me that this shouldn't be a problem with passwords. If you just want to fill up 64 bits, saying that your password should be a length that is a multiple of 8 is more of a WTF than saying it should be exactly 8. But is there some problem with padding a password with 0'd bits to fill the 64 bit blocks? BTW, I'm also of the opinion that hashes are far better, but I'm curious about this. :)
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family."Dustin Metzgar wrote:
A triple DES block is 64 bits, so if your password is greater than 8 characters, then it would have to do more than one block.
actually worse than that. DES requires a 56bit key, triple DES 3 unique 56bit keys, when your password is generated shorter or longer than 8/24 characters there is a procedure for increasing or decreasing the key to be exactly 56/168bits. That procedure is what has been adjusted for the known flaws in DES.
Dustin Metzgar wrote:
But is there some problem with padding a password with 0'd bits to fill the 64 bit blocks?
yes, this is exactly what you do NOT want to do. Introduction of fewer bits into the stream causes the flaws in DES to occur. If you could take the bits of a lesser or more complex key and "shuffle" them "perfectly" this would occur less often. The result is a preprocessing of the DES block key into the required 56bit key, that procedure has to ensure that the resulting 56bit key doesn't carry a large enough empty spot of bits to highlight the flaws of the DES algorithm. The hope of triple DES was by running it three times on three keys, it would improve complexity enough, and it does increase it, just not above 128bit equivalent key due to masking of the leaking bits.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I was perusing the daily WTF and found this: http://thedailywtf.com/forums/thread/98876.aspx[^] One of the rules for the password was that it contain exactly 8 characters. From a user's perspective this sounds like a really stupid rule. But what I was wondering was if the system uses a block cipher, then they'd have to store the length of the password along with the encrypted password. That's so they can remove the garbage that is left over when decrypting. Is this some kind of common practice to get around having to store the password length or is there something else that would require a password to be an exact number of characters? Or is it just a WTF? Do any of you cryptography gurus have some insight on this?
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family." -
Dustin Metzgar wrote:
A triple DES block is 64 bits, so if your password is greater than 8 characters, then it would have to do more than one block.
actually worse than that. DES requires a 56bit key, triple DES 3 unique 56bit keys, when your password is generated shorter or longer than 8/24 characters there is a procedure for increasing or decreasing the key to be exactly 56/168bits. That procedure is what has been adjusted for the known flaws in DES.
Dustin Metzgar wrote:
But is there some problem with padding a password with 0'd bits to fill the 64 bit blocks?
yes, this is exactly what you do NOT want to do. Introduction of fewer bits into the stream causes the flaws in DES to occur. If you could take the bits of a lesser or more complex key and "shuffle" them "perfectly" this would occur less often. The result is a preprocessing of the DES block key into the required 56bit key, that procedure has to ensure that the resulting 56bit key doesn't carry a large enough empty spot of bits to highlight the flaws of the DES algorithm. The hope of triple DES was by running it three times on three keys, it would improve complexity enough, and it does increase it, just not above 128bit equivalent key due to masking of the leaking bits.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Cool, that gives me some idea of the difference between DES and Triple DES. I'm always learning new things on this site.
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family." -
That's what I thought - but everytime I try to find a good function, google returns elaborate garbage.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify! || Fold With Us! || sighistUse SHA-256 (SHA-1 has had some flaws suggested), and use the CryptoAPI implementation, or
System.Security.Cryptography. These implementations have been validated by the US National Institute of Science and Technology. You could also use any other implementation that has been validated[^]. Source code you pick up from the net might well work fine, but I'd be happier using an implementation that has been validated.Stability. What an interesting concept. -- Chris Maunder
-
I was perusing the daily WTF and found this: http://thedailywtf.com/forums/thread/98876.aspx[^] One of the rules for the password was that it contain exactly 8 characters. From a user's perspective this sounds like a really stupid rule. But what I was wondering was if the system uses a block cipher, then they'd have to store the length of the password along with the encrypted password. That's so they can remove the garbage that is left over when decrypting. Is this some kind of common practice to get around having to store the password length or is there something else that would require a password to be an exact number of characters? Or is it just a WTF? Do any of you cryptography gurus have some insight on this?
Logifusion[^]
"This isn't a business. I've always thought of it as a source of cheap labor. Like a family."It is a motor insurance site. Ten bucks they have a legacy system, either electronic or manual, that this website is a front-end too. That system probably has password limitations based on outdated restrictions. They probably have lots of financial and audit procedures that they have to stick to and someone somewhere has said "8 character passwords are were it is at, nothing more, nothing less." The geeks do not run that show, pencil pushers do. And I am amazed this even made it into the WTF. Do none of you remember 8 character filenames? That is far more ludicrous than 8 character passwords.
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
-
Use SHA-256 (SHA-1 has had some flaws suggested), and use the CryptoAPI implementation, or
System.Security.Cryptography. These implementations have been validated by the US National Institute of Science and Technology. You could also use any other implementation that has been validated[^]. Source code you pick up from the net might well work fine, but I'd be happier using an implementation that has been validated.Stability. What an interesting concept. -- Chris Maunder
Mike Dimmick wrote:
but I'd be happier using an implementation that has been validated
It is very easy to validate the result of a one way hash function. But I'm guessing you mean that the code itself has been deemed robust from a software engineer's point of view.
-- In Hypno-Vision