Fair enough, that might be true - but it points to a deficiency in medical training, not a fundamental incapacity. For gods sake, these people study for at least 6 years to become a doctor, at least make them take stats 101!
Yes, that is true, and such advertising can be quite insidious. But it is at least targetted at the right audience, ie people best equipped to make a well-informed decision. The insidious part comes when the marketing becomes more than just a sales pitch, and turns into free gifts (bribes) or worse.
I disagree with your claim that doctors don't have time, knowledge or inclination to investigate the claims directly, and are more likely to be swayed by the fancy literature and free lunch accompanying the salesperson. All doctors at least know how to read a technical report, and know where to go to get further information (eg, journal literature). Maybe some doctors don't have time to do this, or take the easy option and rely on the sales pitch, but at least they do have the necessary technical background.
Wow, as an Australian, I find this pharma marketing so bizarre. Except for over-the-counter stuff like pain killers, there is no advertising of medical products in Australia (same for NZ, UK, probably most of the rest of the western world in fact).
How can a non-expert have any idea what the best treatment is for a disease like schizophrenia? Indeed, for anything more serious than a head cold? I can imagine someone doing some serious research and making a suggestion to their doctor (who will hopefully either say 'good idea', or 'not a good idea, because....'), but basing a complex drug treatment choice on a magazine or TV ad? WTF?
Besides, big pharma spends more money on marketing than they do on research. Since probably 99% of that marketing budget is spent in the USA alone, it is incredibly wasteful.
So here goes: I challenge you to find a continuously-maintained linux distribution from October 25, 2001 (debian seems like a good candidate, network install is cheating, no harm in using virtualbox, if you can) and upgrade it to the point where it is identical in features and functionality to a fresh install of a debian release from March 5, 2010.
My desktop machine has been a continually updating gentoo box since at least 2003. I think I have the original install disc somewhere, I think there is a good chance you could install it, do 'emerge sync' (sync the package repository to the current version), 'emerge portage' (update to the latest version of the package management tools), 'emerge -uD world' (update the installed packages). and be good to go. On the other hand, I wouldn't be too surprised if such an ancient version of portage can't handle the current repository and ebuild structure.
Oh, another thought: most likely, virtually all of the packages from the old install wouldn't exist in the current portage tree. I'm not sure if that would cause a problem - possibly not, if it just updates to the current version of the named packages.
Read up on metrics here. Most of your fallacies and misrepresentations of my arguments are due to ignorance of this subject.
Now you are being duplicitous. What fallacies? What misrepresentations? If you think I've got anything in the final analysis wrong, please tell me - it might also help in winning the lotto!
We have been discussing a specific problem, of whether there is a significant advantage to frequently changing a password. This is a well-defined problem: if you have two people working in the same office, person A has the same password for 20 years, and person B changes their password every month, then is it easier for a cracker to brute-force person A's password compared with person B?. I calculated the expected number of attempts needed to brute-force the password, and I also calculated the probabilities to crack the password after a fixed number of attempts. I believe I have shown that there is a small difference, but it is not significant - at most a factor 2 in the average number of crack attempts needed to break the password. This also has an applications to lotto strategy - buying lots of tickets in a single game of lotto is a better strategy than buying single tickets in lots of games, but the difference is small. For most situations, the effect on the chances of winning is negligible.
Chief fallacy at present: Your arguments, examples and calculations miss the effect of corporate policy on blocking/delaying IP/account/region on detecting an attempt to crack.
I've been analyzing the situation in terms of the expected number of attempts required to brute-force the password. Management could certainly make use of this information in formulating a specific policy, and that may result in slowing down the rate of attacks. That doesn't change the number of attacks required to crack the password, so it doesn't change anything in my analysis.
On the other hand, the 'metric' you came up with, is based on the size of the keyspace divided by the rate of password changes. You have yet to provide any evidence that this 'metric' has any relevance to the problem. Indeed, it suggests that you have fallen for what appears to be a common fallacy, that changing your password N times means that it will take a factor N times longer for a cracker to guess your password. A bit of thought at how lotto games work shows that this cannot possibly be true.
Once upon a time, there was a sysadmin A. He didn't change his password for 20 years. Maximum number of password crack attempts per unit time(Max attempt flux): (keyspace/20years).
I agree completely that if the attacker can scan the entire keyspace in 20 years, then sysadmin A's password will be cracked.
From your earlier post:
There was another contemporary sysadmin B. He changed his password every month.
If the attacker can scan the entire keyspace in 1 month, then sysadmin B's password will be cracked. Yes, I think we all agree on that. The question is, is sysadmin B really that more secure than sysadmin A? You seem to be trying to make an argument that sysadmin B is '240 times more secure', but your argument isn't very coherent and I don't understand it.
Suppose the attacker is scanning the keyspace more slowly, say he's scanning the entire keyspace in 20 years. Then in that time, sysadmin A will get cracked in that time with 100% probability. But sysadmin B will get cracked in that time with a probability of at least 63%. Is that enough of a difference that sysadmin B can feel a warm glow of safety?
The reason why that there is no absolute maximum number to the attempts it could take to crack sysadmin B's password, is because it is periodically changing. Unless the cracker can scan the entire keyspace in 1 month (in which case sysadmin B is guaranteed to be cracked anyway), then sysadmin B always has a chance that he changes his password in time to foil the attacker. But that is really a false hope: if the attacker is determined enough to scans the entire keyspace 10 times, for example, then sysadmin B only has a 1 in 20,000 chance of evading the cracker. The number 240 never comes into it.
The point of my previous argument was to show that it doesn't matter how often sysadmin B changes his password, because even if he changes it to a random key after every attempted crack, this only buys him a factor 2 improvement in the average number of crack attempts required to guess his password. From my previous post:
So you can see that as password is changed more frequently, the number of attempts changes from (keyspace/2) for no password changes, to (keyspace) if the password is changed frequently.
If you don't understand my argument, please read the lotto analogy instead.
If I told you that you had a 100% chance of being killed in an accident in vehicle A, but only a 63% chance of being killed if you were in the same accident vehicle B, which one would you take to work?
Neither, I'd walk or catch a bus.
Seriously, I'm really thinking of the cost required to brute-force a password to a dedicated attacker out to get you. To get the 100% probability from exhausting the key-space, you need a serious attacker anyway, because he needs to keep track of his failed attempts so that he doesn't repeat any passwords. If its a serious attacker, then it is unlikely he'll give up at just the moment where the difference between random passwords and fixed passwords is significant. All he has to do is wait for 2x, or, if he really needs to, 5x longer (or use more parallel attempts) and he's got the probability of getting you up to 86% (or 6 in 7 chance), or 99%.
If you really need a bit more security, then you are much better off adding a couple of characters onto your password. That is going to give you about 5000x improvement. Which would you prefer, a 63% chance of being killed, or a 0.02% chance?
On the contrary, one could say it is over 2x as difficult to crack.
That is a rather dangerous attitude I think. Lets put it a slightly different way. Suppose that you know that there are attackers out there capable of brute-forcing a 120-bit key. Would you therefore be content with a 121-bit key? After all, it is 2x as difficult to crack.
If I wanted to get a 2x increase in safety, then adding one more bit to my password is much easier than switching to a regime where I change my password every month. But crypto security doesn't work that way. To be really safe, you'd better have a password that a really hard to brute-force, like 1000, or 10000 or more times difficult than the capabilities of the best resourced bad guy you can imagine. And if you have this, factors of 2 don't matter. Actually, I think probably even if you have a very weak password, an extra factor 2 doesn't mean much.
Let me frame it in a slightly different way. I guess you have some kind of lotto game in your country? Imagine that the lotto results represent the randomly changing password, and you are an 'attacker', trying to guess the password (lotto results). Suppose, for the sake of argument, that the chances of wining a game of lotto are one in a million, for a single entry in one game. Can you answer:
What is the maximum number of lotto games you need to play in order to guarantee that you will win?
On average, how many games of lotto do you need to play to increase your chances of winning from one in a million up to something substantial, say 50% ? 90% ?
How do your answers to the above questions change, if instead of buying a single ticket in each of N different lotto draws, you instead enter N times in one single draw?
Finally, is there any difference between how the probabilities work in this lotto example, versus the cracker attacking passwords? If so, what are the differences?
Wow, this is getting to be pretty abusive. Lets try and keep the flames down a bit.
Hope you can at least read bold. For maximum number of password crack attempts, one would have to exhaust the keyspace. The number 240 comes from there.
No, that isn't correct. If the password is frequently changing, then strictly speaking there isn't a maximum. There is a small probability that takes a very large number of attempts to guess the password. That probability is vanishingly small, for even a moderate number of attempts. For example, I went through the math here, which shows that if you make a number of attempts of 10 times the size of the keyspace, then (for a large keyspace) the probability of guessing the key is 99.995%. But to get the probability to be exactly 1, requires an infinite number of attempts.
Lets go through and calculate the probabilities explicitly. Lets assume that the attacker tries all passwords in order, only repeating passwords after exhausting the keyspace. Firstly, lets consider the case where the target password is fixed. As you previously explained, the probability of guessing the password on the P^th try (after P-1 unsuccessful tries) is 1/(N-P+1). Now, in general, the probability of guessing the password in exactlyP tries is (1-probability_of_guessing_password_in_P-1_tries) * probability_of_guessing_password_on_Pth_try. The probability of guessing the password in any of the previous tries is (N-P+1)/N, which gives a total probability of min(1,P/N). This is as we expect, since if we exhaust the keyspace by trying all N guesses, then the probability of getting the key is 1.
The second case, for a randomly changing password, is covered here. Putting this together, for an example where the keyspace is size 1,000,000, we get, for the probability of cracking a fixed key and a randomly-changing key, after P attempts:
Yes, there is a difference. No, I don't think that difference is significant. If the attacker has enough resources to have a chance at cracking a fixed password, then he's still got a good chance at attacking a randomly changing password with the same effort. If the attacker exhausts the keyspace then he's got 100% chance of finding my fixed key, but his probability of finding your randomly changing key is still 63%, which is still very good odds for the attacker.
A week later, they're locked out again, and have to start over.
So you advocate changing passwords weekly? For the reason that if your system gets pwned, then after a week when you change your password, your system will magically become un-pwned? Sorry, I'm not convinced.
The way I do it, is that all of my passwords are in text files, stored on the most secure system I have access to. That only allows public key logins from known hosts (or other hosts, via an extra challenge-response step) to one front-end host. The passwords themselves are all random, usually longest supported length. I rarely type them, 99.9% of the time I 'cat' the relevant text file, double-click select the password and middle-click paste it into the password box.
I think, in this setup, encrypting the password text files wouldn't add much security. The login procedure is more secure than any password I could actually remember, and if I kept a hard copy of a longer key in my wallet I'd almost certainly lose it sooner or later.
IIRC - The password aging was part of IBM's recommendations for implementing DES. This is a proven best practice for perfect systems. This advice on changing passwords monthly is based on the assumption that the ends are secure, for example mainframe to mainframe communications.
Weren't session keys invented to overcome this problem?
Assume a password of finite size and finite alphabet, which fixes the size of the keyspace to N, and random guesses at the password (selecting passwords from the keyspace). When guessing 'without replacement' (i.e. you don't try the same guess twice), after N guesses the probability of having guessed the password is 1.
Yes. Or, equivalently, the average number of guesses required is N/2; half time time it will take more than N/2 (and possibly up to N tries), half the time it will take less than N/2.
If instead the password would be changed after each guess, you don't gain any information about the password (by ruling out an increasing number of possibilities through guessing), and as a result your chances of guessing the password stay at 1/N all the time.
Right. Probability of guessing the password is 1/N each time, independently of how many times you have guessed in the past.
That means that after P attempts, the probability that at least one of those attempts guessed the right password is
1/N (probability of guessing it correctly at first attempt) + (1-1/N) * 1/N (probability of guessing it wrong at the first attempt, and right at the second attempt) + (1-1/N)^2 * 1/N (probability of guessing it wrong at the first 2 attempts, and right at the 3rd attempt) +...
=
1 - (1-1/N)^P
To get the password with probability strictly equal 1, you need to take P to infinity. But that is a silly limit. If you are satisfied with a probability of to crack the password of (1-x), for some small x, then you need N*ln(1/x) attempts. For example, to have a 90% probability of cracking the password, you need around 2.3*N attempts. This compares with 0.9*N attempts to get 90% chance to crack the password in the case where it isn't changing. This gives a safety factor of 2.56, which isn't much! [*]
When we take as a metric for systrem security the probability of guessing the password *in the limit*, the increase in security of changing passwords would be a factor 1/(1/N) = N, which for any realistically sized keyspace is a lot more than 2.
No, you've fallen for the fallacy that changing the key significantly increases the difficulty of cracking it. There is a simple conceptual argument as to why that cannot be true: random guesses have a probability 1/N of guessing the key by pure chance. So if you try N guesses then you must have a probability `close' to 1. It doesn't matter whether the key is changing or not, the probability is still 1/N per guess.
I think I'm finally realizing why some places have these stupid rules: even a moderately technical crowd on slashdot don't understand simple probability arguments so what hope does a PHB have?
[*] This is measuring the probability of cracking the password after P attempts, which isn't the same thing as the previous calculation, which was looking at the average number of attempts to crack the password. The distribution isn't symmetric, so the average number of attempts required isn't the same as the number of attempts required to have a 50% chance of finding the password. The average number of attempts to crack a frequently changing password is only twice the number of attempts needed to crack a fixed password, even though ensuring a very high probability of cracking a frequently changing password takes many attempts. This is because most of the time, it will only take around N attempts to guess the password, but because it is always changing, there is a small probability that it takes much more than N attempts. The probability that you fail to get the password becomes vanishingly small as have more attempts. For example, if you try 10*N times, the probability of guessing the password is 99.995%.
The reason to expire passwords and passkeys, is that by sampling encrypted content, the key can eventually be brute forced off line.
You can be reasonably certain this will take months/years. The higher the value of the payload, the more frequently you need to change your keys,
Ahh, finally some sensible reasoning! Ok, so the argument is that if someone sniffs enough encrypted packets then they can brute-force the key, and that is a pure computation problem that doesn't require any interaction with other systems that might be able to detect it. That is a good point, and that is why SSH2 has a key regeneration protocol, to automatically rekey long-lived SSH sessions.
How does this argument apply to passwords? If someone manages to obtain an encrypted password file for my bank's internet banking credentials, then they can brute-force the plaintext passwords, offline. But is that really a threat that an end-user needs to protect against? The security of the password file is a problem for the bank, not me. Anyway, I'd be worried that if an attacker has enough resources to make brute-forcing my password practical at all, then they have an unacceptably high risk of being able to do it within the one month window before my password changes again. For example, if its going to take them a year to scan the entire keyspace, then within one month they have a 1/12 chance of cracking my account, which is already bad. I think the bank ought to be able to have enough security around their password databases to make this kind of attack difficult, or at least detectable, so they can warn their customers and lock out accounts as necessary.
By making me change my password once a month, the bank gets some questionable improvement in their own security, in case someone hacks their internal systems and obtains their password files. But that is their problem - as an end user, changing my password is a relatively risky procedure, eg I have to type it in twice, which gives twice the opportunity for someone to peek over my shoulder. If I need to change my password every month then in practice it is either going to be a very weak password that I can remember easily, or I'm going to have to write it down somewhere. For every method I can think of in which someone gets my password because of something I've done wrong, a system where I change my password every month (1) doesn't help in this situation at all, and (2) only serves to give more opportunities for someone to get my password, since I need to type it in more times, and (3) if my password is simpler as a result of having to change it frequently then this just gets easier.
In other words, it seems to be about the bank making policies that give a minor improvement in their own internal security, at the expense of inconveniencing and reducing the security of their customers.
Mathematically it doesn't make any sense, but that's the way normal people (phb's etc) think.
Right, that is what I suspected. But it doesn't make any sense so why should I do it? I am still enough of an optimist that I prefer to have rules based on sound technical arguments, not vague and incorrect 'gut feelings' etc. I'd like to think that comething like a bank would have a better grasp of security.
Also, there was another sysadmin C: who never changed the password. Asymptotically, he will be cracked.
If his password is good, then he will get cracked after, on average, a number of attempts equal to half the size of the keyspace.
With an 8-character (upper/lower/digit/special 72 possibilities per character) password, that gives an average of 361,102,068,154,368 attempts from the systematic attacker, trying all passwords in sequence.
Versus sysadmin B who changes his password once a month, and will be cracked after an average of 722,204,136,308,736 attempts (assuming it takes the attacker much longer than 1 month to scan the keyspace, so that sysadmin B's password changes many times during the attack window).
Do you think that difference is important? I definitely do not.
Max attempt flux is 240 times for sysadmin B as compared to sysadmin A. Using this metric, one could say periodically changing the password is 240 times more secure.
That is nuts. Didn't I just demonstrate that the maximum increase in safety from changing your password frequently is a factor 2? That is, even if there is a determined, systematic attacker doing a dictionary attack, then he will, on average, crack sysadmin B's password in half the time it takes to crack sysadmin A's password. Your 'attempt flux metric' is voodoo. You might as well base your IT security policy on the 'metric' of how often each sysadmin eats sushi.
Note that to get the full factor 2 security from changing the password, you need to change it very rapidly in comparison to the time it takes the attacker to scan the keyspace. If an attacker decides to target you and puts in enough resources to scan the keyspace in one week, then the fact that you change your password every month is irrelevant. Even if it takes the attacker a month to scan the keyspace, changing your password once in that time only gives a factor 1.5 improvement in the time it takes him to crack you. If it takes the attacker a year or so to scan the keyspace, then changing your password every month gives close to the full factor 2. Big fat hairy deal.
And all this assumes that the attacker is systematic and remembers which passwords he's already tried. If I was going to try a brute force attack, I wouldn't even bother with that, I'd just select trial passwords randomly from the dictionary. It is only going to slow me down by at most a factor 2, compared with the best I could do if the target never changes his password. But now my cracking program doesn't need to keep any state information and it's much easier to run in parallel.
Additionally, by keeping changing the password, one prevents long-running situations when someone has acquired (by cracking, maybe got lucky, key-logger, maybe tortured an employee, maybe used an ex-employee, lot depends on company policies) the password and he doesn't want to lock out other administrators but just silently carry on his activities and systematically delete his traces.
Ahh, I was wondering when this excuse would show up. If your computer gets pwned, then you are nuts if you think that changing your password will suddenly make your computer un-pwned. Anyone who has enough know-how to systematically delete his traces will also have enough know-how to put in a difficult-to-detect back door.
The case of an ex-employee sniffing around but not actually damaging anything is maybe,... maybe..., one case where changing passwords might be useful. But this isn't really about cracking, it is about password management. If the IT policies are sensible, then the ex-employee's login will be locked out anyway. If someone else gave away a password, then yeah they should change it. So yeah if you are the kind of person that gives away your passwords, then I can see that there is an argument that you should change them frequently. But that has nothing to do with protecting against dictionary attacks.
Absolutely wrong premises. Probability is not 1/10 per attack. It is 1/10 for the first attack, 1/9 for the second, 1/8 for the third and so on. If he chooses sequential pattern, and goes from 0-9: After the 1st failed attack, the attacker "knows" that 0 is not the password.
That is true, but it has no substantial effect. It changes the shape of the distribution, but it doesn't have a dramatic effect on the number of attacks required, at most a factor 2. Actually I was wrong before when I suggested that the average would be unchanged, I didn't think about it enough beforehand; the correct result is that changing the password at a sufficiently fast rate gives a factor 2 improvement in the time required for an attacker to guess it. But that isn't significant.
If you want to try this at home, pick a random number from 0-9, to simulate the password, and then start a dictionary attack in sequence (it doesn't matter which sequence, and it doesn't matter where you start from) and see how many attempts you need to get the password. You should find that you need an average of 5 attempts. Now try changing the password randomly each time, and you should see that it takes an average of 10 attempts.
1. From the start of his attack to its end, he can assume that password does not change. In this case, there are chances that he has already tried a password and then you have changed it. So it is possible that he has exhausted the set of possible passwords, and yet not cracked the password successfully.
Yes, this is true. That is what leads to the factor 2 saving in time.
2. He can assume the password can change any time. This makes him retry the same passwords over and over again. Not sure what heuristic will serve him best here, but it is certain that this one takes more time, effort and energy of the attacker.
Also true, but the extra time is only a factor 2. I think that is pretty much irrelevant.
Just for kicks, and because I can't be bothered sitting down with a pen & paper, I tried a numerical experiment. Password from 0-1024, and I calculated the average number of times it takes to guess the password using a dictionary attack; once the complete sequence of passwords have been tried, go back to the start of the dictionary and repeat. Now vary how often a new password is generated, once every N attacks, for N=1,2,4,8,...,1024. One million repetitions of each test. The results are:
N Average number of attacks to guess password 1 1023.43 2 1022.33 4 1021.78 8 1019.33 32 1007.93 64 992.064 128 959.957 256 895.785 512 768.717 1024 512.309
So you can see that as password is changed more frequently, the number of attempts changes from (keyspace/2) for no password changes, to (keyspace) if the password is changed frequently. I'm not convinced this is worthwhile - if an attacker is going to brute-force my keys then making it a factor 2 harder is negligible. If I wanted to make my password stronger I'd do much better by not bothering to change my password and instead adding one more character to it.
Effectiveness of a dictionary attack = (probability of the attacker guessing it each attempt) * (number of attempts)
That is, the number of attack attempts. It has nothing to do with the frequency of changing the target password.
So the statistics don't work out the same. You missed the (number of attempts) part.
I don't think I missed anything, read my sentence again: There is a certain probability of the attacker guessing it each attempt...
Let me try again, with an actual example. Suppose, for simplicity, that my password is a single digit, 0 - 9. Now, if the attacker is trying to guess my password, then he has a 1/10 chance of guessing my password at each attempt. This probability is the same, no matter what sequence the attacker chooses (random or sequential, doesn't matter what sequence). It is also exactly the same probability no matter how often I change my password. A probability of 1/10 per attack means that on average it will take 5 attempts for the attacker to guess my password. Changing my password has no effect on the time taken to crack it.
If you are not convinced of this, try it with some dice. You will find that the probability of getting a specific fixed outcome (eg, '3') is 1 in 6. You will also find that if you change your password every time (say, by rolling a second dice and using that as your new password), the probability of the attacker guessing your new password (ie, roll two dice and calculate the probability getting a double) is again 1 in 6.
A weak password can eventually be cracked by a slow, dispersed dictionary attack;
But changing it to another weak password has essentially no effect on the effectiveness of a dictionary attack. There is a certain probability of the attacker guessing it each attempt, and that probability doesn't change no matter how often you change your password. It doesn't matter whether the attacker is attempting passwords sequentially or randomly, the statistics works out the same.
This way, you don't have to worry about someone you gave the password to a year ago, or who otherwise found out about it (post-it, etc.) and now decides to do something about it because you p*ssed them off;
This I can kinda get, if you are a person who frequently gives out their passwords. I don't think I've ever done that, for any non-throwaway password. I'd temporarily change my password, and change it back again later.
I also fail to see how anyone can maintain even a single password that they change every month, without some kind of system. Especially if it is a strong password, that takes some time&effort to remember.
Change the passwords every few months (and use different ones for each site).
Using different passwords for each site I get, but what is the reasoning behind changing passwords every few months? If you have a good password, it won't be guessed or brute-forced. If you have a weak password, changing it to another weak password monthly won't do a thing.
I'm really curious about this, because it is such a common recommendation. My bank even say that they only guarantee fraud losses on internet transfers if you changed your password within the last month - but they also recommend a 'system' for your password, which is to add the month number (1 to 12) to the end of your normal password! There is no way that can increase security, and several demonstrable ways it decreases security.
I think defining correctness as "producing the desired results" is pretty reasonable. Sure correct doesn't mean robust, but they are different things and this discussion has been about correctness.
I agree that correctness and robustness are different things. Robustness is about flexibility of a specification. Non-robust code (and programs) have very tight specifications and are useful only only under a narrow set of circumstances.
Corretness is (in my, and I think fairly common definition) a question of whether the specification is implemented correctly. From an architectural point of view, correctness may be applied to the specification itself, so one can talk about correctness of the specification, but that isn't what I'm talking about here. Correctness of the program is purely about bugs (or hopefully lack of!) in the software implementing the specification.
According to this definition, it is possible to have an incorrect program that still produces correct results. This may happen, for example, if the program calls a standard library function incorrectly (ie, violating a precondition), but the implementation of that function is such that it just happens to work anyway. Such a piece of software may still be useful, no denying that, but I assert that it is still not correct. A formal proof will show that it is incorrect because internal invariants will not be met. In some cases it may be possible to devise a new set of specifications (preconditions and invariants) such that the program is correct. But that means that you need to be able to modify the specifications, and obviously for something like a standard library function you have no control over the external specification.
I think defining correctness as "producing the desired results is pretty reasonable. Sure correct doesn't mean robust, but they are different things and this discussion has been about correctness.
No, from an engineering point of view it isn't reasonable at all. I can see where you are coming from, and that you want to have a definition of correctness that your verification tools can use, so you can prove that some piece of software is or isn't 'correct'. I'm sure that makes for great marketing! But without formal verification against a specification, there is no way to certify that the design is correct against even the smallest change in the system. I'm going to harp on about this because its an important point that you might not be able to see from your ivory tower[*].
Lets take a more traditional engineering example: a bridge. The bridge designer comes up with a set of specifications for each part, and a bunch of people build the parts and deliver them, and some more people put the bridge together. Now, suppose that the person making one particular cable screws it up, and instead of being able to withstand a force of 100,000N, it can only stand a force of 1,000N before breaking. According to the design specification of the bridge, this cable must be able to withstand the full 100,000N when undergoing extreme stresses (high winds, lots of traffic, etc). Now also suppose that by a lucky coincidence, the person making the support structure elsewhere in the bridge did an excellent job and over-engineered their components such that, even under high stresses, the cable is never tested beyond 1,000N, instead the forces are distributed among other parts of the bridge. The result is, the bridge doesn't fall down.
I'm betting at this point that you would say that the bridge is correct. After all, your verification tools will throw some inputs (traffic, weather, etc) at the bridge, covering all of the extremes and corner cases, and it doesn't fall down, so it must be correct!
The only problem is, that there is a good chance a whole bunch of people will die, sooner or later. Eg, suppose that later on when the bridge needs some maintenance on some of the supports, a different contractor is brought in, who looks at the spec, builds the component, and puts it in the bridge. He can do this, while still satisfying the specification, in such a way that suddenly the cable, that previously only had 1,000N force on it, now has the full design specification of 100,000N and the cable promptly snaps. You are still asking "where is the actual bug?". If you cannot see where the bug is, I think there is no hope.
The above example is a very close analogy to the Javascript code. The bridge support structure is the Javascript standard library, and the cable is the Microsoft browser choice web page. The code in the web page doesn't meet the specification, but due to a lucky accident, it happens to work. Umm, except that it doesn't: on none of the browsers tested, does it actually work. The only way it would work is if the Javascript sort function was implemented in the precise way that you seem to advocate, a naive QuickSort that just happens to have the property that if you violate the precondition in a particular way, the algorithm will violate its postcondition in a particular way that coincides with what you actually want. If you want to call that correct then I guess no one can stop you, but when you sell your verification software to customers you should make it very clear how you are defining 'correct'. I rather suspect their definitions will disagree!
This is why, in some schools of thought, it is considered a serious bug if a function does anything sensible with input beyond what is specified in the precondition. It can hide bugs elsewhere in the code, because it opens up the possibility that you accidentally misuse a function, but that misuse is hidden and is likely to surface and bite you when you least expect it. For a simple exa
If you define correctness as "producing the desired results on one particular version of one particular platform", then you have a recipe for non-robust code that won't survive in the real world.
No what Rob demonstrated was that replacing the call to sort made the error go away. But several things were changed here as well (most notably the random number generation and initial seeding were probably altered substantially).
Damn, I've been wasting my time. Now I know you didn't properly read the article. He includes the test programs he used. They are pretty short, and easy to verify that there is no difference at all in the random number generation, nor in initial seeding (whatever that is supposed to mean - you seed the random generator once at the start of the program [or better still, when the machine is powered on], and never touch it afterwards). What a waste of a couple of hours.
So, while he is right that calling sort to get a purmutation is a bad idea and he is (probably) right that the sort was the problem, this is never actually shown in the article. He just assumes that the bug went away so it must mean that the sort was the problem (but as I showed above this need not be the case).
Not worth responding to, just reinforces that you never looked at the source code.
As for your concern for me, I doubt if my code has appeared on TheDailyWTF, but I do know that I recently had some of my work in the ACM proceedings of "Verification Model Checking and Abstact Interpetation" on modeling the semantics of programs for later verification applications. So, I do know a bit about program correctness and specification. How about you?
Conference proceedings don't count for much. I can't see any evidence that you know anything about devloping robust programs. Not that I'd expect you to, it is quite a different game to developing verification software anyway (although if the verification software itself needs tp be robust, then we have a problem).
You do realize there is a difference between code that is dangerous (but technically correct) and code that is actually buggy. As per my quicksort example. Dangerous, but correct.
I don't think that there is such a thing as "dangerous (but technically correct)". Given a specific implementation, it may just happen to do what you want it to, if you supply a specially crafted input that violates the spec. I would call that dangerous, incorrect, but may happen to work on a specific implementation. There is no reason to expect that it will continue to work on the next release of the software.
It would be fair enough, if you wrote your own algorithm, lets call it marron_sort(), that has the spec:
marron_sort(array, comp): Precondition: none Postcondition: array' is permuted according to the QuickSort algorithm as specified on Wikipedia, as retrieved on 1st March 2010
This algorithm serves (at least) two purposes: (1) given a comparitor defining a strict weak ordering, it sorts the array. (2) if the comparitor returns unbiased coin tosses, then the array is permuted by an unbiased random shuffle.
I hope that you can agree that this is a rather weird specification! In any event, this is nothing like the actual specification of Javascript sort(). The fact that there is one theoretical implementation that does what you want when given invalid input doesn't mean that it is in any way reasonable to expect the same behavior for random implementation X. Especially since the 'one theoretical implementation' in this case is non-optimal.
Calling my quicksort routine with an invalid compare function clearly violates the intent of the contract abstractions but functionally produces the correct results.
No it doesn't. The QuickSort specifies a postcondition that on algorithm exit, the array is sorted. There is no way that a non-sorted array can be considered 'correct'.
The same may happen with your sqrt(-1) example, it is a bad idea from a modularity standpoint but may be functionally correct.
Huh what? Firstly, what does 'modularity' have to do with it? And secondly, can you explain how calling sqrt(-1) 'may be functionally correct' ? What do you expect it do to?
If you want to talk about if that is the case for the browser selection, well, I am glad you agree that determining if the implementation of the JS quicksort routine causes the bug (or if it is something else) would be a good idea.
One more time, for the road: the bug was caused by some n00b programmer calling the Javascript sort function with an invalid comparison function. I don't understand why you seem to be trying to blame the implementor of the Javascript sort function, when the sort function is completely correct and obeys the specification! There is probably no browser in existence that would actually implement sort in the way that you apparently think it should be. If you really think that strongly about it, I suggest you talk to the W3C. I don't expect they'll pay any attention to you though.
Unfortunately the author of the article was happy to jump to premature (although not unreasonable) conclusions.
What? Are you on drugs? Rob wrote a test program, demonstrated that the code written by the MS programmer generated a non-uniform distribution, and verified that a correctly written random shuffle algorithm produces a uniform distribution, using the same test program. Rob also went through the code and identified the specific bug that caused the problem: incorrect use of the sort() function. How can you possibly call that a premature conclusion?
During this thread, I have identified at least two sort fragments that are likely to be similar to code used in real-world implementations of the Javascript sort()
Slashdot Mirror
Fair enough, that might be true - but it points to a deficiency in medical training, not a fundamental incapacity. For gods sake, these people study for at least 6 years to become a doctor, at least make them take stats 101!
Yes, that is true, and such advertising can be quite insidious. But it is at least targetted at the right audience, ie people best equipped to make a well-informed decision. The insidious part comes when the marketing becomes more than just a sales pitch, and turns into free gifts (bribes) or worse.
I disagree with your claim that doctors don't have time, knowledge or inclination to investigate the claims directly, and are more likely to be swayed by the fancy literature and free lunch accompanying the salesperson. All doctors at least know how to read a technical report, and know where to go to get further information (eg, journal literature). Maybe some doctors don't have time to do this, or take the easy option and rely on the sales pitch, but at least they do have the necessary technical background.
Wow, as an Australian, I find this pharma marketing so bizarre. Except for over-the-counter stuff like pain killers, there is no advertising of medical products in Australia (same for NZ, UK, probably most of the rest of the western world in fact).
How can a non-expert have any idea what the best treatment is for a disease like schizophrenia? Indeed, for anything more serious than a head cold? I can imagine someone doing some serious research and making a suggestion to their doctor (who will hopefully either say 'good idea', or 'not a good idea, because....'), but basing a complex drug treatment choice on a magazine or TV ad? WTF?
Besides, big pharma spends more money on marketing than they do on research. Since probably 99% of that marketing budget is spent in the USA alone, it is incredibly wasteful.
My desktop machine has been a continually updating gentoo box since at least 2003. I think I have the original install disc somewhere, I think there is a good chance you could install it, do 'emerge sync' (sync the package repository to the current version), 'emerge portage' (update to the latest version of the package management tools), 'emerge -uD world' (update the installed packages). and be good to go. On the other hand, I wouldn't be too surprised if such an ancient version of portage can't handle the current repository and ebuild structure.
Oh, another thought: most likely, virtually all of the packages from the old install wouldn't exist in the current portage tree. I'm not sure if that would cause a problem - possibly not, if it just updates to the current version of the named packages.
Now you are being duplicitous. What fallacies? What misrepresentations? If you think I've got anything in the final analysis wrong, please tell me - it might also help in winning the lotto!
We have been discussing a specific problem, of whether there is a significant advantage to frequently changing a password. This is a well-defined problem: if you have two people working in the same office, person A has the same password for 20 years, and person B changes their password every month, then is it easier for a cracker to brute-force person A's password compared with person B?. I calculated the expected number of attempts needed to brute-force the password, and I also calculated the probabilities to crack the password after a fixed number of attempts. I believe I have shown that there is a small difference, but it is not significant - at most a factor 2 in the average number of crack attempts needed to break the password. This also has an applications to lotto strategy - buying lots of tickets in a single game of lotto is a better strategy than buying single tickets in lots of games, but the difference is small. For most situations, the effect on the chances of winning is negligible.
I've been analyzing the situation in terms of the expected number of attempts required to brute-force the password. Management could certainly make use of this information in formulating a specific policy, and that may result in slowing down the rate of attacks. That doesn't change the number of attacks required to crack the password, so it doesn't change anything in my analysis.
On the other hand, the 'metric' you came up with, is based on the size of the keyspace divided by the rate of password changes. You have yet to provide any evidence that this 'metric' has any relevance to the problem. Indeed, it suggests that you have fallen for what appears to be a common fallacy, that changing your password N times means that it will take a factor N times longer for a cracker to guess your password. A bit of thought at how lotto games work shows that this cannot possibly be true.
I agree completely that if the attacker can scan the entire keyspace in 20 years, then sysadmin A's password will be cracked.
From your earlier post:
If the attacker can scan the entire keyspace in 1 month, then sysadmin B's password will be cracked. Yes, I think we all agree on that. The question is, is sysadmin B really that more secure than sysadmin A? You seem to be trying to make an argument that sysadmin B is '240 times more secure', but your argument isn't very coherent and I don't understand it.
Suppose the attacker is scanning the keyspace more slowly, say he's scanning the entire keyspace in 20 years. Then in that time, sysadmin A will get cracked in that time with 100% probability. But sysadmin B will get cracked in that time with a probability of at least 63%. Is that enough of a difference that sysadmin B can feel a warm glow of safety?
The reason why that there is no absolute maximum number to the attempts it could take to crack sysadmin B's password, is because it is periodically changing. Unless the cracker can scan the entire keyspace in 1 month (in which case sysadmin B is guaranteed to be cracked anyway), then sysadmin B always has a chance that he changes his password in time to foil the attacker. But that is really a false hope: if the attacker is determined enough to scans the entire keyspace 10 times, for example, then sysadmin B only has a 1 in 20,000 chance of evading the cracker. The number 240 never comes into it.
The point of my previous argument was to show that it doesn't matter how often sysadmin B changes his password, because even if he changes it to a random key after every attempted crack, this only buys him a factor 2 improvement in the average number of crack attempts required to guess his password. From my previous post:
If you don't understand my argument, please read the lotto analogy instead.
Neither, I'd walk or catch a bus.
Seriously, I'm really thinking of the cost required to brute-force a password to a dedicated attacker out to get you. To get the 100% probability from exhausting the key-space, you need a serious attacker anyway, because he needs to keep track of his failed attempts so that he doesn't repeat any passwords. If its a serious attacker, then it is unlikely he'll give up at just the moment where the difference between random passwords and fixed passwords is significant. All he has to do is wait for 2x, or, if he really needs to, 5x longer (or use more parallel attempts) and he's got the probability of getting you up to 86% (or 6 in 7 chance), or 99%.
If you really need a bit more security, then you are much better off adding a couple of characters onto your password. That is going to give you about 5000x improvement. Which would you prefer, a 63% chance of being killed, or a 0.02% chance?
That is a rather dangerous attitude I think. Lets put it a slightly different way. Suppose that you know that there are attackers out there capable of brute-forcing a 120-bit key. Would you therefore be content with a 121-bit key? After all, it is 2x as difficult to crack.
If I wanted to get a 2x increase in safety, then adding one more bit to my password is much easier than switching to a regime where I change my password every month. But crypto security doesn't work that way. To be really safe, you'd better have a password that a really hard to brute-force, like 1000, or 10000 or more times difficult than the capabilities of the best resourced bad guy you can imagine. And if you have this, factors of 2 don't matter. Actually, I think probably even if you have a very weak password, an extra factor 2 doesn't mean much.
Let me frame it in a slightly different way. I guess you have some kind of lotto game in your country? Imagine that the lotto results represent the randomly changing password, and you are an 'attacker', trying to guess the password (lotto results). Suppose, for the sake of argument, that the chances of wining a game of lotto are one in a million, for a single entry in one game. Can you answer:
Wow, this is getting to be pretty abusive. Lets try and keep the flames down a bit.
No, that isn't correct. If the password is frequently changing, then strictly speaking there isn't a maximum. There is a small probability that takes a very large number of attempts to guess the password. That probability is vanishingly small, for even a moderate number of attempts. For example, I went through the math here, which shows that if you make a number of attempts of 10 times the size of the keyspace, then (for a large keyspace) the probability of guessing the key is 99.995%. But to get the probability to be exactly 1, requires an infinite number of attempts.
Lets go through and calculate the probabilities explicitly. Lets assume that the attacker tries all passwords in order, only repeating passwords after exhausting the keyspace. Firstly, lets consider the case where the target password is fixed. As you previously explained, the probability of guessing the password on the P^th try (after P-1 unsuccessful tries) is 1/(N-P+1). Now, in general, the probability of guessing the password in exactlyP tries is (1-probability_of_guessing_password_in_P-1_tries) * probability_of_guessing_password_on_Pth_try. The probability of guessing the password in any of the previous tries is (N-P+1)/N, which gives a total probability of min(1,P/N). This is as we expect, since if we exhaust the keyspace by trying all N guesses, then the probability of getting the key is 1.
The second case, for a randomly changing password, is covered here. Putting this together, for an example where the keyspace is size 1,000,000, we get, for the probability of cracking a fixed key and a randomly-changing key, after P attempts:
Yes, there is a difference. No, I don't think that difference is significant. If the attacker has enough resources to have a chance at cracking a fixed password, then he's still got a good chance at attacking a randomly changing password with the same effort. If the attacker exhausts the keyspace then he's got 100% chance of finding my fixed key, but his probability of finding your randomly changing key is still 63%, which is still very good odds for the attacker.
So you advocate changing passwords weekly? For the reason that if your system gets pwned, then after a week when you change your password, your system will magically become un-pwned? Sorry, I'm not convinced.
The way I do it, is that all of my passwords are in text files, stored on the most secure system I have access to. That only allows public key logins from known hosts (or other hosts, via an extra challenge-response step) to one front-end host. The passwords themselves are all random, usually longest supported length. I rarely type them, 99.9% of the time I 'cat' the relevant text file, double-click select the password and middle-click paste it into the password box.
I think, in this setup, encrypting the password text files wouldn't add much security. The login procedure is more secure than any password I could actually remember, and if I kept a hard copy of a longer key in my wallet I'd almost certainly lose it sooner or later.
Weren't session keys invented to overcome this problem?
Yes. Or, equivalently, the average number of guesses required is N/2; half time time it will take more than N/2 (and possibly up to N tries), half the time it will take less than N/2.
Right. Probability of guessing the password is 1/N each time, independently of how many times you have guessed in the past.
That means that after P attempts, the probability that at least one of those attempts guessed the right password is
To get the password with probability strictly equal 1, you need to take P to infinity. But that is a silly limit. If you are satisfied with a probability of to crack the password of (1-x), for some small x, then you need N*ln(1/x) attempts. For example, to have a 90% probability of cracking the password, you need around 2.3*N attempts. This compares with 0.9*N attempts to get 90% chance to crack the password in the case where it isn't changing. This gives a safety factor of 2.56, which isn't much! [*]
No, you've fallen for the fallacy that changing the key significantly increases the difficulty of cracking it. There is a simple conceptual argument as to why that cannot be true: random guesses have a probability 1/N of guessing the key by pure chance. So if you try N guesses then you must have a probability `close' to 1. It doesn't matter whether the key is changing or not, the probability is still 1/N per guess.
I think I'm finally realizing why some places have these stupid rules: even a moderately technical crowd on slashdot don't understand simple probability arguments so what hope does a PHB have?
[*] This is measuring the probability of cracking the password after P attempts, which isn't the same thing as the previous calculation, which was looking at the average number of attempts to crack the password. The distribution isn't symmetric, so the average number of attempts required isn't the same as the number of attempts required to have a 50% chance of finding the password. The average number of attempts to crack a frequently changing password is only twice the number of attempts needed to crack a fixed password, even though ensuring a very high probability of cracking a frequently changing password takes many attempts. This is because most of the time, it will only take around N attempts to guess the password, but because it is always changing, there is a small probability that it takes much more than N attempts. The probability that you fail to get the password becomes vanishingly small as have more attempts. For example, if you try 10*N times, the probability of guessing the password is 99.995%.
Ahh, finally some sensible reasoning! Ok, so the argument is that if someone sniffs enough encrypted packets then they can brute-force the key, and that is a pure computation problem that doesn't require any interaction with other systems that might be able to detect it. That is a good point, and that is why SSH2 has a key regeneration protocol, to automatically rekey long-lived SSH sessions.
How does this argument apply to passwords? If someone manages to obtain an encrypted password file for my bank's internet banking credentials, then they can brute-force the plaintext passwords, offline. But is that really a threat that an end-user needs to protect against? The security of the password file is a problem for the bank, not me. Anyway, I'd be worried that if an attacker has enough resources to make brute-forcing my password practical at all, then they have an unacceptably high risk of being able to do it within the one month window before my password changes again. For example, if its going to take them a year to scan the entire keyspace, then within one month they have a 1/12 chance of cracking my account, which is already bad. I think the bank ought to be able to have enough security around their password databases to make this kind of attack difficult, or at least detectable, so they can warn their customers and lock out accounts as necessary.
By making me change my password once a month, the bank gets some questionable improvement in their own security, in case someone hacks their internal systems and obtains their password files. But that is their problem - as an end user, changing my password is a relatively risky procedure, eg I have to type it in twice, which gives twice the opportunity for someone to peek over my shoulder. If I need to change my password every month then in practice it is either going to be a very weak password that I can remember easily, or I'm going to have to write it down somewhere. For every method I can think of in which someone gets my password because of something I've done wrong, a system where I change my password every month (1) doesn't help in this situation at all, and (2) only serves to give more opportunities for someone to get my password, since I need to type it in more times, and (3) if my password is simpler as a result of having to change it frequently then this just gets easier.
In other words, it seems to be about the bank making policies that give a minor improvement in their own internal security, at the expense of inconveniencing and reducing the security of their customers.
Right, that is what I suspected. But it doesn't make any sense so why should I do it? I am still enough of an optimist that I prefer to have rules based on sound technical arguments, not vague and incorrect 'gut feelings' etc. I'd like to think that comething like a bank would have a better grasp of security.
If his password is good, then he will get cracked after, on average, a number of attempts equal to half the size of the keyspace.
With an 8-character (upper/lower/digit/special 72 possibilities per character) password, that gives an average of 361,102,068,154,368 attempts from the systematic attacker, trying all passwords in sequence.
Versus sysadmin B who changes his password once a month, and will be cracked after an average of 722,204,136,308,736 attempts (assuming it takes the attacker much longer than 1 month to scan the keyspace, so that sysadmin B's password changes many times during the attack window).
Do you think that difference is important? I definitely do not.
That is nuts. Didn't I just demonstrate that the maximum increase in safety from changing your password frequently is a factor 2? That is, even if there is a determined, systematic attacker doing a dictionary attack, then he will, on average, crack sysadmin B's password in half the time it takes to crack sysadmin A's password. Your 'attempt flux metric' is voodoo. You might as well base your IT security policy on the 'metric' of how often each sysadmin eats sushi.
Note that to get the full factor 2 security from changing the password, you need to change it very rapidly in comparison to the time it takes the attacker to scan the keyspace. If an attacker decides to target you and puts in enough resources to scan the keyspace in one week, then the fact that you change your password every month is irrelevant. Even if it takes the attacker a month to scan the keyspace, changing your password once in that time only gives a factor 1.5 improvement in the time it takes him to crack you. If it takes the attacker a year or so to scan the keyspace, then changing your password every month gives close to the full factor 2. Big fat hairy deal.
And all this assumes that the attacker is systematic and remembers which passwords he's already tried. If I was going to try a brute force attack, I wouldn't even bother with that, I'd just select trial passwords randomly from the dictionary. It is only going to slow me down by at most a factor 2, compared with the best I could do if the target never changes his password. But now my cracking program doesn't need to keep any state information and it's much easier to run in parallel.
Ahh, I was wondering when this excuse would show up. If your computer gets pwned, then you are nuts if you think that changing your password will suddenly make your computer un-pwned. Anyone who has enough know-how to systematically delete his traces will also have enough know-how to put in a difficult-to-detect back door.
The case of an ex-employee sniffing around but not actually damaging anything is maybe, ... maybe ..., one case where changing passwords might be useful. But this isn't really about cracking, it is about password management. If the IT policies are sensible, then the ex-employee's login will be locked out anyway. If someone else gave away a password, then yeah they should change it. So yeah if you are the kind of person that gives away your passwords, then I can see that there is an argument that you should change them frequently. But that has nothing to do with protecting against dictionary attacks.
That is true, but it has no substantial effect. It changes the shape of the distribution, but it doesn't have a dramatic effect on the number of attacks required, at most a factor 2. Actually I was wrong before when I suggested that the average would be unchanged, I didn't think about it enough beforehand; the correct result is that changing the password at a sufficiently fast rate gives a factor 2 improvement in the time required for an attacker to guess it. But that isn't significant.
If you want to try this at home, pick a random number from 0-9, to simulate the password, and then start a dictionary attack in sequence (it doesn't matter which sequence, and it doesn't matter where you start from) and see how many attempts you need to get the password. You should find that you need an average of 5 attempts. Now try changing the password randomly each time, and you should see that it takes an average of 10 attempts.
Yes, this is true. That is what leads to the factor 2 saving in time.
Also true, but the extra time is only a factor 2. I think that is pretty much irrelevant.
Just for kicks, and because I can't be bothered sitting down with a pen & paper, I tried a numerical experiment. Password from 0-1024, and I calculated the average number of times it takes to guess the password using a dictionary attack; once the complete sequence of passwords have been tried, go back to the start of the dictionary and repeat. Now vary how often a new password is generated, once every N attacks, for N=1,2,4,8,...,1024. One million repetitions of each test. The results are:
So you can see that as password is changed more frequently, the number of attempts changes from (keyspace/2) for no password changes, to (keyspace) if the password is changed frequently. I'm not convinced this is worthwhile - if an attacker is going to brute-force my keys then making it a factor 2 harder is negligible. If I wanted to make my password stronger I'd do much better by not bothering to change my password and instead adding one more character to it.
That is, the number of attack attempts. It has nothing to do with the frequency of changing the target password.
I don't think I missed anything, read my sentence again: There is a certain probability of the attacker guessing it each attempt...
Let me try again, with an actual example. Suppose, for simplicity, that my password is a single digit, 0 - 9. Now, if the attacker is trying to guess my password, then he has a 1/10 chance of guessing my password at each attempt. This probability is the same, no matter what sequence the attacker chooses (random or sequential, doesn't matter what sequence). It is also exactly the same probability no matter how often I change my password. A probability of 1/10 per attack means that on average it will take 5 attempts for the attacker to guess my password. Changing my password has no effect on the time taken to crack it.
If you are not convinced of this, try it with some dice. You will find that the probability of getting a specific fixed outcome (eg, '3') is 1 in 6. You will also find that if you change your password every time (say, by rolling a second dice and using that as your new password), the probability of the attacker guessing your new password (ie, roll two dice and calculate the probability getting a double) is again 1 in 6.
But changing it to another weak password has essentially no effect on the effectiveness of a dictionary attack. There is a certain probability of the attacker guessing it each attempt, and that probability doesn't change no matter how often you change your password. It doesn't matter whether the attacker is attempting passwords sequentially or randomly, the statistics works out the same.
This I can kinda get, if you are a person who frequently gives out their passwords. I don't think I've ever done that, for any non-throwaway password. I'd temporarily change my password, and change it back again later.
I also fail to see how anyone can maintain even a single password that they change every month, without some kind of system. Especially if it is a strong password, that takes some time&effort to remember.
Using different passwords for each site I get, but what is the reasoning behind changing passwords every few months? If you have a good password, it won't be guessed or brute-forced. If you have a weak password, changing it to another weak password monthly won't do a thing.
I'm really curious about this, because it is such a common recommendation. My bank even say that they only guarantee fraud losses on internet transfers if you changed your password within the last month - but they also recommend a 'system' for your password, which is to add the month number (1 to 12) to the end of your normal password! There is no way that can increase security, and several demonstrable ways it decreases security.
I agree that correctness and robustness are different things. Robustness is about flexibility of a specification. Non-robust code (and programs) have very tight specifications and are useful only only under a narrow set of circumstances.
Corretness is (in my, and I think fairly common definition) a question of whether the specification is implemented correctly. From an architectural point of view, correctness may be applied to the specification itself, so one can talk about correctness of the specification, but that isn't what I'm talking about here. Correctness of the program is purely about bugs (or hopefully lack of!) in the software implementing the specification.
According to this definition, it is possible to have an incorrect program that still produces correct results. This may happen, for example, if the program calls a standard library function incorrectly (ie, violating a precondition), but the implementation of that function is such that it just happens to work anyway. Such a piece of software may still be useful, no denying that, but I assert that it is still not correct. A formal proof will show that it is incorrect because internal invariants will not be met. In some cases it may be possible to devise a new set of specifications (preconditions and invariants) such that the program is correct. But that means that you need to be able to modify the specifications, and obviously for something like a standard library function you have no control over the external specification.
No, from an engineering point of view it isn't reasonable at all. I can see where you are coming from, and that you want to have a definition of correctness that your verification tools can use, so you can prove that some piece of software is or isn't 'correct'. I'm sure that makes for great marketing! But without formal verification against a specification, there is no way to certify that the design is correct against even the smallest change in the system. I'm going to harp on about this because its an important point that you might not be able to see from your ivory tower[*].
Lets take a more traditional engineering example: a bridge. The bridge designer comes up with a set of specifications for each part, and a bunch of people build the parts and deliver them, and some more people put the bridge together. Now, suppose that the person making one particular cable screws it up, and instead of being able to withstand a force of 100,000N, it can only stand a force of 1,000N before breaking. According to the design specification of the bridge, this cable must be able to withstand the full 100,000N when undergoing extreme stresses (high winds, lots of traffic, etc). Now also suppose that by a lucky coincidence, the person making the support structure elsewhere in the bridge did an excellent job and over-engineered their components such that, even under high stresses, the cable is never tested beyond 1,000N, instead the forces are distributed among other parts of the bridge. The result is, the bridge doesn't fall down.
I'm betting at this point that you would say that the bridge is correct. After all, your verification tools will throw some inputs (traffic, weather, etc) at the bridge, covering all of the extremes and corner cases, and it doesn't fall down, so it must be correct!
The only problem is, that there is a good chance a whole bunch of people will die, sooner or later. Eg, suppose that later on when the bridge needs some maintenance on some of the supports, a different contractor is brought in, who looks at the spec, builds the component, and puts it in the bridge. He can do this, while still satisfying the specification, in such a way that suddenly the cable, that previously only had 1,000N force on it, now has the full design specification of 100,000N and the cable promptly snaps. You are still asking "where is the actual bug?". If you cannot see where the bug is, I think there is no hope.
The above example is a very close analogy to the Javascript code. The bridge support structure is the Javascript standard library, and the cable is the Microsoft browser choice web page. The code in the web page doesn't meet the specification, but due to a lucky accident, it happens to work. Umm, except that it doesn't: on none of the browsers tested, does it actually work. The only way it would work is if the Javascript sort function was implemented in the precise way that you seem to advocate, a naive QuickSort that just happens to have the property that if you violate the precondition in a particular way, the algorithm will violate its postcondition in a particular way that coincides with what you actually want. If you want to call that correct then I guess no one can stop you, but when you sell your verification software to customers you should make it very clear how you are defining 'correct'. I rather suspect their definitions will disagree!
This is why, in some schools of thought, it is considered a serious bug if a function does anything sensible with input beyond what is specified in the precondition. It can hide bugs elsewhere in the code, because it opens up the possibility that you accidentally misuse a function, but that misuse is hidden and is likely to surface and bite you when you least expect it. For a simple exa
If you define correctness as "producing the desired results on one particular version of one particular platform", then you have a recipe for non-robust code that won't survive in the real world.
Damn, I've been wasting my time. Now I know you didn't properly read the article. He includes the test programs he used. They are pretty short, and easy to verify that there is no difference at all in the random number generation, nor in initial seeding (whatever that is supposed to mean - you seed the random generator once at the start of the program [or better still, when the machine is powered on], and never touch it afterwards). What a waste of a couple of hours.
Not worth responding to, just reinforces that you never looked at the source code.
Conference proceedings don't count for much. I can't see any evidence that you know anything about devloping robust programs. Not that I'd expect you to, it is quite a different game to developing verification software anyway (although if the verification software itself needs tp be robust, then we have a problem).
I don't think that there is such a thing as "dangerous (but technically correct)". Given a specific implementation, it may just happen to do what you want it to, if you supply a specially crafted input that violates the spec. I would call that dangerous, incorrect, but may happen to work on a specific implementation. There is no reason to expect that it will continue to work on the next release of the software.
It would be fair enough, if you wrote your own algorithm, lets call it marron_sort(), that has the spec:
This algorithm serves (at least) two purposes: (1) given a comparitor defining a strict weak ordering, it sorts the array. (2) if the comparitor returns unbiased coin tosses, then the array is permuted by an unbiased random shuffle.
I hope that you can agree that this is a rather weird specification! In any event, this is nothing like the actual specification of Javascript sort(). The fact that there is one theoretical implementation that does what you want when given invalid input doesn't mean that it is in any way reasonable to expect the same behavior for random implementation X. Especially since the 'one theoretical implementation' in this case is non-optimal.
No it doesn't. The QuickSort specifies a postcondition that on algorithm exit, the array is sorted. There is no way that a non-sorted array can be considered 'correct'.
Huh what? Firstly, what does 'modularity' have to do with it? And secondly, can you explain how calling sqrt(-1) 'may be functionally correct' ? What do you expect it do to?
One more time, for the road: the bug was caused by some n00b programmer calling the Javascript sort function with an invalid comparison function. I don't understand why you seem to be trying to blame the implementor of the Javascript sort function, when the sort function is completely correct and obeys the specification! There is probably no browser in existence that would actually implement sort in the way that you apparently think it should be. If you really think that strongly about it, I suggest you talk to the W3C. I don't expect they'll pay any attention to you though.
What? Are you on drugs? Rob wrote a test program, demonstrated that the code written by the MS programmer generated a non-uniform distribution, and verified that a correctly written random shuffle algorithm produces a uniform distribution, using the same test program. Rob also went through the code and identified the specific bug that caused the problem: incorrect use of the sort() function. How can you possibly call that a premature conclusion?
During this thread, I have identified at least two sort fragments that are likely to be similar to code used in real-world implementations of the Javascript sort()