The Daily WTF: Curious Perversions in Information Technology

2010-09-15 Reply Admin

someGuy:
Timing Attacks are BS.
Could someone devise a test on a closed system, while in control of every aspect of the network infrastructure, with the ability to reduce as much noise as possible?

Xbox 360 was broken by a timing attack http://www.google.com/search?hl=en&q=timing+attack+xbox

Timing attacks are real and they work a lot better than you think

2010-09-15 Reply Admin

the Xbox 360 is a Closed system. A time attack against that doesn't really show much in terms of the feasibility of a time attack used over the internet against a server (the context of the discussion)

EvanED · 2010-09-15 Reply Admin

You definitely shouldn't discount the possibility of timing attacks when writing software that runs locally. (One of my favorite security papers exploited a race condition and time-of-check-to-time-of-use vulnerability in some versions of lpr to gain access to anyone's documents.)

That said, if that's a web program or similar, the length of time it takes to do a simple string comparison like that will be almost unmeasurable. Even that would probably be very difficult locally. (The Xbox attack seems to be based on hashing, which is a much more expensive operation than a few byte comparisons.)

That said, why are you (generic 'you') assuming this is a web program? The summary even says it's in a common code library, which is actually probably pretty bad.

2010-09-15 Reply Admin

EvanED:
You definitely shouldn't discount the possibility of timing attacks when writing software that runs locally. (One of my favorite security papers exploited a race condition and time-of-check-to-time-of-use vulnerability in some versions of lpr to gain access to anyone's documents.)
That said, if that's a web program or similar, the length of time it takes to do a simple string comparison like that will be almost unmeasurable. Even that would probably be very difficult locally. (The Xbox attack seems to be based on hashing, which is a much more expensive operation than a few byte comparisons.)

That said, why are you (generic 'you') assuming this is a web program? The summary even says it's in a common code library, which is actually probably pretty bad.

TRWTF is that there is no "reply" or "quote" buttons available anywhere on this site.

2010-09-15 Reply Admin

It's a deep comparison. Similar to a deep copy. (thedailywtf.com Articles Deep-Copy.aspx)

Totally redundant, existing only to provide a potential bottleneck for experienced programmers to use as insurance (thedailywtf.com Articles The-Speedup-Loop.aspx) and give the inexperienced programmers peace of mind that they haven't created a bug this time.

2010-09-15 Reply Admin

The first article that was linked brought it up in the context of web servers

EvanED · 2010-09-15 Reply Admin

Larry:
TRWTF is that there is no "reply" or "quote" buttons available anywhere on this site.

Huh? I didn't quote anyone because I wasn't replying to any one particular post.

2010-09-15 Reply Admin

Dave:
Believe it or not, this is how TD Canada Trust's (Canada's second largest financial institution) online banking works.
They only allow for a password up to 8 characters. If you enter more than 8 characters the system truncates anything beyond 8 chars and validates.

Other things about TD Canada Trust's passwords:

Password can only be 5-8 characters in length

no special characters are allowed

System does not differentiate between upper and lower case.

I've raised these issues with their support team however they state that these faults are actually features. They even said that because hundreds of people forget their passwords that they are willing to sacrifice a little security for ease of use.

Ironically enough, having password requirements so out of line with everyone else encourages probably one of the most important password policies: to not reuse passwords. You could have gobbledygook for a password hashed and salted and sauteed to perfection (mmm... sauteed gobbledygook) but all the best efforts to secure things internally are for naught if the unit between the chair and the monitor:

a) Installs a keylogger. b) Re-uses the password somewhere else. c) Lets someone else see their password. d) Screws up in some way I can't anticipate.

Realistically, if TDCT has taken all the other proper measures, having a really weak password isn't going to hurt them overly. (though limiting it to 8 might hurt security in the case of catastrophic failure) And, well, it definitely makes customer service's job a lot easier. It's been said it before, and I'll say it again: if you've been "hacked" 99% of the time, it's your fault.

ALL that said, major banking institution, target for attacks, significant potential for losses, should know better, people probably reusing passwords in an dictionary somewhere anyways, etc. etc.

As for the article, aside from not checking length (if you're assured same length, you should probably assert on that in case someone changes something), too many contexts in which this isn't a wtf.

2010-09-15 Reply Admin

My God. It's full of stars!

2010-09-15 Reply Admin

v:
In fact passwords _should_ be treated differently: you should use a constant time comparison (e.g. not returning once a mismatched character is found as in the above)

I remember reading an article once about a timing attack that correlated the timing of key presses to the location of letters/numbers on the keyboard to help weed out likely passwords. Of course, this wouldn't work on web software.

Interesting stuff, timing attacks.

2010-09-15 Reply Admin

Dave:
3) System does not differentiate between upper and lower case.

They didn't have the other problems you listed, but I used to have a brokerage account whose web access required all passwords to be lowercase. They didn't tell people that when setting up the password, though. When someone set a new password, the site would silently convert whatever was entered into lowercase without telling the user and store it that way as the password. Then when putting in the password to log in, the check was case-sensitive. I.e. you had to log in using all lowercase even if you had specified a mixed-case password when you set it up. The login would fail if you entered a mixed-case password the same way you'd entered it when initially setting the password up.

2010-09-15 Reply Admin

Who needs passwords?

A fellow I knew at one company came up with his own way to verify users. Instead of asking for a password, it would ask for something from the person's payroll file.

For example, it might ask for the person's address. Or it may ask how much had been deducted from his paycheck last year for medical insurance. Or maybe how much his year to date pay was.

It turned out to be pretty difficult to log on. Sometimes it would be an easy question, but usually you had to have a copy of your payroll records, up to date as of the last payroll, in front of you to log onto the computer.

And, of course, if they had just run payroll and you didn't have the latest copy of your records yet, you couldn't log in at all.

The idea never really caught on.

Bumble Bee Tuna · 2010-09-15 Reply Admin

Steve H:
BG:
In TheDailyWTF comment system you can type your password in and it appears as *'s!

Weird! Where does the completely spurious apostrophe come from?

Spurious? When you're trying to make a post criticizing another user for their writing skills, you should probably not use a word whose meaning you don't know.

Perhaps you meant superfluous.

2010-09-15 Reply Admin

Somebody else remember similar vulnerability in GRUB?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555195

2010-09-15 Reply Admin

frits:
You guys laugh, but this is the exact code the CLR uses for String.Equals(), except they use a loop over a switch for optimization.

Prove it!

2010-09-15 Reply Admin

"they’re sometimes encrypted with some sort of “hash”"

TRWTF is people who don't understand the difference between hashing and encryption.

2010-09-15 Reply Admin

Remote timing attacks do exist:

http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/

Also a great book by Michal Zalewski, in which the topic is explored: http://lcamtuf.coredump.cx/silence.shtml

2010-09-15 Reply Admin

Um I'd love to see a proof of concept of that one.. I can see that working for shared hosting providers (e.g.), but over the internet? Doubt it.

But they're right.. why risk anything when the fix is so trivial?

2010-09-15 Reply Admin

NullUserException:
"they’re sometimes encrypted with some sort of “hash”"
TRWTF is people who don't understand the difference between hashing and encryption.

A hash is an encryption, of sorts. Just one that is impossible to decrypt.

2010-09-15 Reply Admin

Steve H:
BG:
In TheDailyWTF comment system you can type your password in and it appears as *'s!

Weird! Where does the completely spurious apostrophe come from?

My, what an incontinent adjective you chose there. Or is that part of some inside joke?

2010-09-15 Reply Admin

someGuy:
Could someone devise a test on a closed system, while in control of every aspect of the network infrastructure, with the ability to reduce as much noise as possible?
perhaps

could you utilize those techniques to crack a password at Digg.com?

no.

Are you sure? Can you verify this? How do you know this hasn't already happened?

If it did, would Digg.com (or whoever) publicly admit it and risk similar attacks? Would they even know it happened, or that it happened as a result of a timing attack? The user might know something was up, but would they really know that someone else actually knows their password? Or even that it was cracked due to a timing attack?

There are reasons that scientists set up controlled environments (or closed systems) to test theories, and it's not just because they have less control over things "in the wild."

You're also pointing out that there is a key difference in a closed system vs. over a network. Fair enough. Here's a study of timing attacks over a network for you:

http://www.cs.cmu.edu/~dbrumley/pubs/openssltiming.pdf

2010-09-15 Reply Admin

Bob:
v:
In fact passwords _should_ be treated differently: you should use a constant time comparison (e.g. not returning once a mismatched character is found as in the above)
What kind of squirrely, hypothetical fantasy world do you live in? Any cracker that attempted to break the password this way would be confounded by the packet latency that would take place between the submit and the return. THAT ITSELF is a variable time parameter, and would completely prempt any time-based "cracking" algorithm.

Who said anything about the password verification taking place at the other end of a network link?

2010-09-15 Reply Admin

Anon:
Bob:
v:
In fact passwords _should_ be treated differently: you should use a constant time comparison (e.g. not returning once a mismatched character is found as in the above)
What kind of squirrely, hypothetical fantasy world do you live in? Any cracker that attempted to break the password this way would be confounded by the packet latency that would take place between the submit and the return. THAT ITSELF is a variable time parameter, and would completely prempt any time-based "cracking" algorithm.

Who said anything about the password verification taking place at the other end of a network link?

Duh. Webpage.

2010-09-15 Reply Admin

boog:
someGuy:
Could someone devise a test on a closed system, while in control of every aspect of the network infrastructure, with the ability to reduce as much noise as possible?
perhaps

could you utilize those techniques to crack a password at Digg.com?

no.

Are you sure? Can you verify this? How do you know this hasn't already happened?
If it did, would Digg.com (or whoever) publicly admit it and risk similar attacks? Would they even know it happened, or that it happened as a result of a timing attack? The user might know something was up, but would they really know that someone else actually knows their password? Or even that it was cracked due to a timing attack?

There are reasons that scientists set up controlled environments (or closed systems) to test theories, and it's not just because they have less control over things "in the wild."

You're also pointing out that there is a key difference in a closed system vs. over a network. Fair enough. Here's a study of timing attacks over a network for you:

http://www.cs.cmu.edu/~dbrumley/pubs/openssltiming.pdf

And here's a study about how the moon landings were a hoax.

http://en.wikipedia.org/wiki/Moon_landing_hoax

Name your poison: the moon hoax, multiple JFK shooters, illuminati. What's the common thread behind all of these? There's more proof of their existence than there is of the ability to perform time-based password cracking of websites.

TheJasper · 2010-09-15 Reply Admin

Unit Between Chair and Monitor:
Ironically enough, having password requirements so out of line with everyone else encourages probably one of the most important password policies: to not reuse passwords. You could have gobbledygook for a password hashed and salted and sauteed to perfection (mmm... sauteed gobbledygook) but all the best efforts to secure things internally are for naught if the unit between the chair and the monitor:
Realistically, if TDCT has taken all the other proper measures, having a really weak password isn't going to hurt them overly. (though limiting it to 8 might hurt security in the case of catastrophic failure) And, well, it definitely makes customer service's job a lot easier. It's been said it before, and I'll say it again: if you've been "hacked" 99% of the time, it's your fault.

ALL that said, major banking institution, target for attacks, significant potential for losses, should know better, people probably reusing passwords in an dictionary somewhere anyways, etc. etc.

My bank forces a new password every year AND gives you a seemingly random string as username. That is sort of annoying actually as you really have to have your computer remember it. However, your username could be seen as a public immutable part of your password. Which is why it bugs me to no end that many modern osses (or rather login managers) expose which users are on a computer. Not to mention you may want a hidden account for other than security purposes.

2010-09-15 Reply Admin

Mike:

public static bool passwordsMatch(string pass1, string pass2) {
  // bgates : TODO - add security stuff 
  return true;
}

You missed a little...

public static bool passwordsMatch(string pass1, string pass2) {
  // bgates 1995: TODO - add security stuff 
  //return true;
// bgates 1998: The most secure version of Windows ever yet
//if (tries < 3) {
//  return false;
//} else {
//  return true;
//}
// bgates 2000: The most secure version of Windows ever yet
//if (username eq 'administrator') {
//  return true;
//} else {
//  bsod();
//}
// bgates 2003: The most secure version of Windows ever yet
//if (current.WindowsUpdates() and (bugs.ZeroDay == 0)) {
//  if (pass1.equals(pass2)) {
//    return true;
//  } else {
//    return false;
//  }
//} else {
//  return true;
//}
// bgates 2007: The most secure version of Windows ever yet
//if (count.UAC_dialog_boxes() > 50) {
//  return true;
//} else {
//  TODO: something
//  return passwordsMatch(string pass1, string pass2);

//}
// bgates 2009: The most secure version of Windows ever yet
// TODO: check how Linux does it
return bool:int(rand(0.3));
}

2010-09-15 Reply Admin

Bob:
Name your poison: the moon hoax, multiple JFK shooters, illuminati. What's the common thread behind all of these? There's more proof of their existence than there is of the ability to perform time-based password cracking of websites.

The illuminati shot JFK from their secret moon base, but you didn't hear it from me.

2010-09-15 Reply Admin

Scott:
Okay, so if psswd2 is longer than psswd1 they can still match. WTF!?

No, because the helper function that calls this succeeds only on passwordsMatch(userpass, pwlist[i]) and passwordsMatch(pwlist[i], userpass)

-Harrow.

2010-09-15 Reply Admin

The best part about this bug is if they make the correct password pass2 and the one being checked pass1, an attacker can not only log in, but can figure out what the real password is one character at a time! Assuming an 8-character password using 62 alphanumerics, this would take 62*8 tries instead of 62^8 tries.

2010-09-15 Reply Admin

boog:
You're also pointing out that there is a key difference in a closed system vs. over a network. Fair enough. Here's a study of timing attacks over a network for you:
http://www.cs.cmu.edu/~dbrumley/pubs/openssltiming.pdf

One of the first sentences in the abstract: "an OpenSSL-based web server running on a machine in the local network." I think we all agree that the jitter in a local network where you're probably even the only user is minimal, but how is that realistic?

And the reason to believe that nothing is in the wild is that security researchers have known about this kind of attacks for decades and still there's no proof of concept anywhere to be found. Compare that to the mass of papers and co for local timing attacks.

2010-09-15 Reply Admin

Bob:
And here's a study about how the moon landings were a hoax.
http://en.wikipedia.org/wiki/Moon_landing_hoax

Name your poison: the moon hoax, multiple JFK shooters, illuminati. What's the common thread behind all of these? There's more proof of their existence than there is of the ability to perform time-based password cracking of websites.

Ok, so we're referring to Wikipedia entries as academic studies now? Strange, it looks more like unsupported allegations and conjecture to me.

Anyhow, aside from completely missing my point, you've sufficiently demonstrated your ability to flat-out deny that scientific evidence contrary to your beliefs even exists. Good for you.

So if scientific evidence is meaningless (as far as you're concerned), let me ask: what exactly would it take to convince you?

TheJasper · 2010-09-15 Reply Admin

boog:
Bob:
And here's a study about how the moon landings were a hoax.
http://en.wikipedia.org/wiki/Moon_landing_hoax

Name your poison: the moon hoax, multiple JFK shooters, illuminati. What's the common thread behind all of these? There's more proof of their existence than there is of the ability to perform time-based password cracking of websites.
Ok, so we're referring to Wikipedia entries as academic studies now? Strange, it looks more like unsupported allegations and conjecture to me.

Anyhow, aside from completely missing my point, you've sufficiently demonstrated your ability to flat-out deny that scientific evidence contrary to your beliefs even exists. Good for you.

So if scientific evidence is meaningless (as far as you're concerned), let me ask: what exactly would it take to convince you?

Don't know about Bob, but I'll take Benjamin Franklin.

2010-09-15 Reply Admin

they’re sometimes encrypted with some sort of “hash”.

And that would be TRWTF. You don't encrypt with hashes. You might hash the password. You might even salt it first. You might even encrypt the resulting hash (though I have no idea why, plenty of apps do this).

But you don't encrypt with a hash. Encryption and hashing are two entirely separate cryptographic operations.

2010-09-15 Reply Admin

Voo:
One of the first sentences in the abstract: "an OpenSSL-based web server running on a machine in the local network." I think we all agree that the jitter in a local network where you're probably even the only user is minimal, but how is that realistic?

Ok, but the following caught my eye in the introduction:

openssltiming.pdf:
We successfully mounted our timing attack between two machines on our campus network. The attacking machine and the server were in different buildings with three routers and multiple switches between them.

If that's still not a suitable enough environment, what would be? Seriously, where's the threshold that makes the evidence go from being "BS" to being "acceptable"?

2010-09-15 Reply Admin

TheJasper:
However, your username could be seen as a public immutable part of your password.

Not if you want to be, you know, correct. A user name is identification: you're saying "I am this person". Effectively, an app/OS/whatever says "yeah? prove it!"; you then provide an authentication token (or multiple tokens) -- in many cases, a password. If you correctly authenticate the identity you assert owning, then all that remains is to determine if that identity is authorized to perform the requested action.

Remembering which identities were recently asserted may, in some cases, pose a privacy risk (e.g. on public terminals), but not much of a general security risk.

2010-09-15 Reply Admin

frits:
SeySayux:
Obviously, everyone knows that if a.length != b.length you should return false even before starting the loop.
Correct implementation of equals (for ascii):
bool equals(String lhs, String rhs) {
     if(rhs.length() != lhs.length()) return false;
     
     for(idx_t i = 0; i < lhs.length(); ++i) {
         if(rhs.at(i) != lhs.at(i)) return false;
     }
     return true;
}
Please tell me it's correct. It's correct, right?
You can optimize and use an object comparison. If (object)rhs == (object)lhs you can go ahead and return true immediately.

no null check?

2010-09-15 Reply Admin

Scott:
Okay, so if psswd2 is longer than psswd1 they can still match. WTF!?

In the older versions of Solaris, they'd stop checking characters after the 8th character, but wouldn't throw an error if you put in a password that was longer than 8 characters.

I found this out by accident when I updated a password that was something like "Password,15?" to something like "Password,18!". It accepted it, but then, later, when I inevitably logged in with the "older" version, it accepted it. A little trial and error proved that it accepted ANY password that started with the first 8 characters, regardless of how many extra characters there were (if any).

2010-09-15 Reply Admin

Am I missing something? Neither the original article nor v's comment made any reference to any network separation between the two parties. It was you that introduced this.

2010-09-15 Reply Admin

This isn't specific to Solaris, it's a consequence of the crypt algorithm, which is the standard UNIX password hashing algorithm.

http://en.wikipedia.org/wiki/Crypt_%28Unix%29 :

"The traditional implementation uses a modified form of the DES algorithm. The user's password is truncated to eight characters, and those are coerced down to only 7-bits each; this forms the 56-bit DES key. That key is then used to encrypt an all-bits-zero block, and then the ciphertext is encrypted again with the same key, and so on for a total of 25 DES encryptions. A 12-bit salt is used to perturb the encryption algorithm, so standard DES implementations can't be used to implement crypt(). The salt and the final ciphertext are encoded into a printable string in a form of base64."

These days the overall weakness of the algorithm makes it unsuitable for secure use, so going forward you'll more often see MD5- and further still SHA-based hashes and the like instead. These hashing algorithms are not limited in their key length and are much stronger cryptographically-speaking than the standard crypt algorithm.

Alex Media · 2010-09-15 Reply Admin

cicobuff:
The Nerve:
Fixed?
public static bool passwordsMatch(string pass1, string pass2)
{
    return pass1.Equals(pass2);
}
Null exception if pass1 is null?

You know you can actually fix that by using:

public static bool passwordsMatch(string pass1, string pass2)
{
    return String.Equals(pass1, pass2);
}

TheJasper · 2010-09-15 Reply Admin

Darren:
TheJasper:
However, your username could be seen as a public immutable part of your password.

Not if you want to be, you know, correct. A user name is identification: you're saying "I am this person". Effectively, an app/OS/whatever says "yeah? prove it!"; you then provide an authentication token (or multiple tokens) -- in many cases, a password. If you correctly authenticate the identity you assert owning, then all that remains is to determine if that identity is authorized to perform the requested action.

Remembering which identities were recently asserted may, in some cases, pose a privacy risk (e.g. on public terminals), but not much of a general security risk.

Well I do want to be, you know, correct.

Assume for a moment that a system is completely invulnerable to all (other) security problems. At this point you can only break in by guessing a known users password. That part may be simple, because Bob always uses the birthday of his wife, Alice. However, Bob's account name is Beelzebob. If you don't know that, you aren't getting in. Revealing the names of your users is a security risk.

You could easily reverse my assertion and say that your password is a private variable part of that identity as both are needed to positively identify you. Following this logic user name and password are both part of your identity. I would say that this is definately so.

Authorization has no relevance to the discussion. I assume you threw it in there to show how clever you are because you know, you know, words. It is, however, pedantic and adds noise to your argument.

So knowing the users available on a system isn't enough. You have to know their user names and passwords, neither of which are enough by themselves. A persons is identified by both the user name and the password. The user name is presumably a unique identifier within the system (I should hope). Once logged in it should be enough to uniquely identify you. Yet many systems will ask for the password again for critical actions. Of course, you say that this is because you might leave your terminal and some malicious guy could do bad things if they didn't do it, but it still comes down to your user name and password being used as your identity, with the private part being essential for purposes of verification.

It's really nice that you try to use bold to strengthen your argument but you should've at least made 'token' bold rather than (just) authentication. At least you should if you want to be, you know, correct.

If you persist in maintaining that revealing user names is not a security risk please provide a list of user names that you use preferably coupled with the names of the systems on which those user names are valid. If you're not willing to do this then I assert you are at least implicitly agreeing with me on this point, if not on the entire argument.

Also, chill out dude.

2010-09-15 Reply Admin

I'm not sure this is all that weird, given that we don't actually know how the method is called. The length stuff might a bit of a concern, but then again just because variables are called 'pass' doesn't mean that they're raw data. This may very well be passing in a hash. This would mean both variables are the same length (nice to check it, I suppose - or use a hard coded value as the hash length would be the same length irrespective of password length (of course, that would make the IndexOutOfBounds exception redundant).

That said, without seeing how this algorithm is used we don't really know that it's all such a bad thing.... Given they use a character array rather than string functions makes me suspect that the user was (mistakenly, probably) thinking that he wasn't dealing with absolutely normal strings, which suggests he expected the values passed to be encrypted or hashed....

condsider:

p1 = getPasswordHashFromDB();
p2 = applyHashFunction(password.get());

accessGranted = passwordsMatc(p1,p2);

Of course, I could be wrong too....

2010-09-15 Reply Admin

TheJasper:
Well I do want to be, you know, correct.

That's good, because coincidentally, you are! (Good for you!)

I was actually reading an interesting chapter in Mitnick's "Art of Deception", where he was talking about "seemingly-innocuous" information. Usernames are a great example of that; most people think there are no security risks associated with usernames. Such individuals are perfect targets for social engineers.

TheJasper · 2010-09-15 Reply Admin

Darren:
they’re sometimes encrypted with some sort of “hash”.

And that would be TRWTF. You don't encrypt with hashes. You might hash the password. You might even salt it first. You might even encrypt the resulting hash (though I have no idea why, plenty of apps do this).

But you don't encrypt with a hash. Encryption and hashing are two entirely separate cryptographic operations.

While strictly speaking you are correct it is entirely acceptable in all but academic papers to refer to it in this way. Also, hashes are very similar to a one way function. Hashes differ mainly in that they may map two distinct inputs to the same output. Cryptographic hashes of course want to avoid this. The term one way encryption is also thrown about, though I would say encryption should be reversible.

In language and communication we often accept statements which do not pass the absolute standards of scientific veracity because we are trying to understand each other rather than trying not to. In your case I could be wrong.

2010-09-15 Reply Admin

TheJasper:

Well I do want to be, you know, correct.

Assume for a moment that a system...

[snip...]

You could easily reverse my assertion...

[snip...]

Authorization has no relevance...

[snip...]

So knowing the users available...

[small novel...]

If you persist in maintaining...

[snip...]

Also, chill out dude.

I will now claim Mike's law of internet debate: As the number of volleys increases, the probability of a heated rant that includes the unintentionally ironic phrase, "chill out", approaches one.

2010-09-15 Reply Admin

Rob:
Sadly, I'm perpetually a keypress away from Eclipse crashing horribly. :(

This is funny because it's true.

I've gotten to the point now where I will sometimes pre-emptively close and reopen Eclipse just to save my workspace in preparation for the crash I know is going to happen the moment I try to move or rename a file.

2010-09-15 Reply Admin

That will throw an exception if pass1 is null.

2010-09-15 Reply Admin

Scott:
Okay, so if psswd2 is longer than psswd1 they can still match. WTF!?

Cisco.com used to be like this. It would only match the first 8(iirc) characters, and everything after that was ignored. I used to have fun giving out 48 character passwords to new colleagues.

2010-09-15 Reply Admin

Actually, the function should accept 2 byte arrays, detect charset (or add another 2 parameters to specify) and perform conversion, then do simple string compare.

Captcha: praesent - intentionally wrong current state.

2010-09-16 Reply Admin

TheJasper:
Darren:
they’re sometimes encrypted with some sort of “hash”.

And that would be TRWTF. You don't encrypt with hashes. You might hash the password. You might even salt it first. You might even encrypt the resulting hash (though I have no idea why, plenty of apps do this).

But you don't encrypt with a hash. Encryption and hashing are two entirely separate cryptographic operations.

While strictly speaking you are correct it is entirely acceptable in all but academic papers to refer to it in this way. Also, hashes are very similar to a one way function. Hashes differ mainly in that they may map two distinct inputs to the same output. Cryptographic hashes of course want to avoid this. The term one way encryption is also thrown about, though I would say encryption should be reversible.

In language and communication we often accept statements which do not pass the absolute standards of scientific veracity because we are trying to understand each other rather than trying not to. In your case I could be wrong.

Yeah, I mean, whats wrong with calling my car a bike... They are both vehicles.

Very Special Strings

Leave a comment on “Very Special Strings”