Perhaps what this article is suggesting is one way for developers of entirely new "hardware" to easily supply operators and types (syntax) to any programming language.
It would be interesting to be able to write program a that talked directly to the nervous system using fairly standard <your language of choice> syntax, that when compiled produced a real piece of nano "machinery".
Oh, and the search engine needs to have some understanding of the pages it's looking at so it can distinguish between pages that are about jaguar planes (or the comic book character) as opposed to pages that just mention them but might actually be about a related topic.
How about you work out some way to do this old saw:
Searching for "Jaguar" the fighter bomber as opposed to "Jaguar" the comic book character.
But then, I'd want you get into natural language processing to determine what the real "topic" was that I meant. Of course I'm assuming a free form field. I'd like to just be able to put in "Jaguar the bomber" or "aeronautical: jaguar" or "plane jaguar" or even "plain jaguar" and have it do a Googlesque "Did you mean 'plane Jaguar'".
Hmm, and a fun API so you could build a search.... query = new Query(); query.setTerm("jaguar"); query.setTopic Hint("plain"); or query.setCanonicalTopic("aeron autical");
There's so many different development environments, servers, languages, libraries, protocols and file formats out there (and more every day) that any project is likely to run into several new ones.
A huge problem with most of the newer ones is that they are half baked. When you run into a problem you can take days to sort it out: There's little documentation and what there is does not go into any depth, no-one is talking about it and if they are they most likely saying "I've got this problem no-one knows anything about, help"
In this sort of environment, a good configuration manager could be priceless.
(Come to think of it, I keep running into this Java configuration problem with WebSphere: log4j and struts want to use different, incompatible versions of commons-logging. Any ideas?)
1) Buy a bunch of pay phones and install them in a big room. 2) Hook them up to computers/modems/whatever 3) Call 1-800 numbers found on spam faxes/junk email all day and night. 4) Profit!!!
At $0.35 a call, how long does it take to pay for the pay phone?
Only problem is that there are no actual objects that you can interact with barring NPCs, doors and the occasional "mission objective".
With no tangible objects, there's nothing to sell/buy. You don't even have an inventory.
Except I'm wrong, you do have an inventory and there are "objects" - Enhancements. You can buy them and sell them (You're wrong too, Influence can also be gained by selling Enhancements). You can also trade Enhancements to other players. So there is an economy but it's very limited.
What, did Who's Who launch it self off the shelf into his hot little hand the second he walked in the door?
Or he has a miniature library he keeps in his pocket and a really good magnifying glass?
It would have taken 20 seconds just to walk in the door. Then he's attributing his knowledge of "which book to look in" to the library, when that was his - some of us have no clue that Whos Who would tell you what books someone has written.
He's vastly understating the time it takes to use the library, probably quoting the time it took once he had the book in his hand. If you factor in having to discover which book(s) to look in and actually walking over to the shelf to find it, the library could and would take a lot longer.
You're right, my maths is bad - it overestimates the danger.
However, my point doesn't I think that most password rules don't force people out of the subset. If someone is going to pick a weak password without the rules then they will still pick a weak password with the rules. Instead of "password", a user might use "password1" - which probably passes the software enforced rules but is also probably in most dictionaries. Yeah, it's going to take longer to search for all simple variations on a dictionary word, but it's still cheaper and faster than doing a brute force attack.
The maths used gives the theoretical number of combinations, yet you yourself guess that 90% of the population are going to base their choice on some miniscule subset of those possible.
You're being too simplistic about it. Do not get your password checking algorithm to do anything except require a certain length (and there are arguments against that), allow the users to enter whatever they like. Imposing software rules in the password generation just weakens your security.
Instead, try this: once they enter their password, run it through a decent, up to date cracking algorithm with a good dictionary.
If you find anything, alert the user that they have a weak password. If your users ignore your password requirements, start disabling their accounts.
It might seem like it only causes a 0.0005% reduction but it's a much much larger fraction.
For example, assuming a 101 keystroke keyboard (being nice and letting you put F keys and other non-printing characters in your password). For a password of length 8, the number of combinations is something like:
It makes some sense, except the crackers had the same thoughts years ago. A good dictionary will not be simply a list of words. It will be a meta-list that the crack algorithm builds passwords from.
It knows that "hello" can be spelled "hello", "h4110", "He1l0" and every other variation. Good ones also will do things like adding a single non-alpha to the end and try combinations of two or more words separated by a non-alpha. A half way decent cracking algorithm will get "H3l10&W0r1D". Don't be surprised if they also get "G2k`9^Q9e`S" and "J4;2-*E-t;F" - both those are also variants on "Hello World".
Sorry, but "y311ow" is almost as weak as "yellow". "jack4betty" is better, but still not good.
You think I'm wrong because you do not understand my argument. You sound like someone who has coded a password routine and are defending yourself.
Get this straight: imposing a minimum length on passwords is not a bad password constraint and should be the only one used as it does not reduce the key space significantly. You are incorrect to argue that there is no reduction as that is simply not true.
Imposing additional rules, such as insisting on an non-alpha significantly reduce the key space. For a password of any given length, if you know at least one character must belong to a subset of the allowable characters, then simply have less work to do.
A very simple example that even you should understand:
You have red balls and green balls. All possible sequences of balls of length two: GG,GR,RG,RR. If you insist on at least one character being a subset (must be green) you reduce your key space to: GG,GR,RG. Searching the reduced key space is less work.
Er, I guess you're just a troll, but what the hell, I've got ten minutes before I have to leave.
Let's assume you have two passwords, X and Y. X and Y both meet some arbitary password constraints.
You also have a dictionary, D1 of 1000 entries.
Let's further assume that X is in the dictionary and Y isn't.
Now, remove all entries from the dictionary that do not meet the password constraints in use giving dictionary D2.
To search the dictionary for X will now take 83% of the time and you WILL find it. The probability of is THE SAME as it was before you reduced the dictionary because the probability of X being one of the removed entries is 0.
To search the dictionary for Y will also take 83% of the time and you WON'T find it. You have again saved time because you were going to do the dictionary attack anyway, but you now finish earlier.
Now you get to do a brute force search for Y and AGAIN, the key space is reduced because you do NOT need to generate/check passwords that do not meet the rules. The brute force attack is shorter because you don't need to check some stuff.
Example: rule: passwords must be at least 2 characters and must include a non alpha. Given: We're only using 2 character passwords. Using simple maths and 101 possible key strokes: 101 * (101 - 52) possible entries, is 4949. No constraints: 101 * 101 + 101 is 10302.
With constraints you have to check less than half the unconstrained set.
And the same users that pick stupid passwords with no constraints are the same users that pick stupid passwords with some alpha shoved in it because the software insists on it.
If you really want a piece of software to eliminate bad passwords, just run some crack utility on your own password file and notify users with ones that turn up.
Your initial attack is a dictionary attack. You eliminate passwords from the dictionary that do not meet the rules for the password you are trying to break. This means that IF the dictionary attack was going to succeed, you now succeed sooner.
If the dictionary attack fails, you then do the brute force attack which simply searches the full key space, which has been reduced by the constraints on the password.
Software enforced password constraints cause low hanging fruit to hang lower.
The number of unconstrained passwords of 9 characters or less would then be: 98,815,257,325,206. No?
Because you don't have to check anything with 5 or less, you reduce the key space to 98,814,936,052,800 combinations, the number you give.
This is less work. Not much, granted, but it's still less. Anything that reduces the key space only needs to be coded into the cracking routines once to achieve that reduction in work every time.
Yup. The length being constrained to greater than some number (typically 6 or 8) characters is about the only password constraint that makes sense some kind of sense, but still - any reduction in keyspace means less work.
Assuming we take the example of the guy who had the 5 byte password that takes 18 days to crack, 1.9% still saves you 8 hours. Not an unuseful amount of time.
It's the daft "must include an non-alpha" and "must start with an alpha (or worse, a capital)" and other brain dead, crack smoking, glue sniffing password "rules" that are the real killers
Now, they enforce basic password etiquette (minimum length, non-alpha character requirement, etc...), which helps the situation somewhat
Er, no? Most "password etiquette" schemes are a complete crock. Generally all they do is reduce the key space and therefore make the passwords easier to brute force attack.
You must have a password of at least 6 characters? Well, there goes everything 5 characters and less - don't have to check those.
Hmm, and while we're at it, most people are going to have a password between 6 and 9 characters, don't bother trying anything else until the second pass.
You have to have at least one non-alpha, well - I can reduce my attack to constrain my guesses around that requirement - just reduced the number of attempts necessary by 24%.
Any other rules you want to add to make attacking the password easier?
Most Australians do not like Koalas much. (see my other post on this subject). They put up with them because stupid tourists pay a lot of money to be peed on. Also, it's fun to go to a tourist trap, stand around the bottom of a tree and point up at it and walk away once the crowd gathers. Couldn't do that if the Koalas were all dead now, could we?
Re:Capture and Sell them!
on
Koalas Gone Wild
·
· Score: 5, Informative
They sleep 14 hours a day, they are grouchy, irritable and they stink.
They have two defense mechanisms: Peeing on things and exceedingly long, tough claws.
They view many things, including being held as threatening and they are not afraid to use both defense mechanisms on short notice.
Koalas are one of the worst pets you could possibly have.
Try asking for the 3% back if you pay by cash. I once bought something for around $900 and insisted that if they didn't give me the 3% back I'd use American Express (6.4% at the time from memory)
Of course... and if the people who buy the products can't afford to buy them any more, then the consumers will be replaced by the foreign consumers who do... and the stockholders who sell their stock because they need an income will be replaced by foreign stockholders... and the executives who can't see past the end of the financial year will be replaced by ones who realize that there's no such thing as a free lunch.
Slashdot Mirror
What maybe a few people have missed is that there will be some incredibly interesting "hardware" out there in the future.
Some people have already demonstrated things like using DNA computers to solve travelling salesman problems, Quantum Computing and Grid Computers.
Perhaps what this article is suggesting is one way for developers of entirely new "hardware" to easily supply operators and types (syntax) to any programming language.
It would be interesting to be able to write program a that talked directly to the nervous system using fairly standard <your language of choice> syntax, that when compiled produced a real piece of nano "machinery".
Oh, and the search engine needs to have some understanding of the pages it's looking at so it can distinguish between pages that are about jaguar planes (or the comic book character) as opposed to pages that just mention them but might actually be about a related topic.
How about you work out some way to do this old saw:
c Hint("plain");n autical");
Searching for "Jaguar" the fighter bomber as opposed to "Jaguar" the comic book character.
But then, I'd want you get into natural language processing to determine what the real "topic" was that I meant. Of course I'm assuming a free form field. I'd like to just be able to put in "Jaguar the bomber" or "aeronautical: jaguar" or "plane jaguar" or even "plain jaguar" and have it do a Googlesque "Did you mean 'plane Jaguar'".
Hmm, and a fun API so you could build a search....
query = new Query();
query.setTerm("jaguar");
query.setTopi
or
query.setCanonicalTopic("aero
There's so many different development environments, servers, languages, libraries, protocols and file formats out there (and more every day) that any project is likely to run into several new ones.
A huge problem with most of the newer ones is that they are half baked. When you run into a problem you can take days to sort it out: There's little documentation and what there is does not go into any depth, no-one is talking about it and if they are they most likely saying "I've got this problem no-one knows anything about, help"
In this sort of environment, a good configuration manager could be priceless.
(Come to think of it, I keep running into this Java configuration problem with WebSphere: log4j and struts want to use different, incompatible versions of commons-logging. Any ideas?)
The guy should sue Amazon, they have the patent on that
Uh, ... I can't help myself....
My new business model:
1) Buy a bunch of pay phones and install them in a big room.
2) Hook them up to computers/modems/whatever
3) Call 1-800 numbers found on spam faxes/junk email all day and night.
4) Profit!!!
At $0.35 a call, how long does it take to pay for the pay phone?
Only problem is that there are no actual objects that you can interact with barring NPCs, doors and the occasional "mission objective".
With no tangible objects, there's nothing to sell/buy. You don't even have an inventory.
Except I'm wrong, you do have an inventory and there are "objects" - Enhancements. You can buy them and sell them (You're wrong too, Influence can also be gained by selling Enhancements). You can also trade Enhancements to other players. So there is an economy but it's very limited.
What, did Who's Who launch it self off the shelf into his hot little hand the second he walked in the door?
Or he has a miniature library he keeps in his pocket and a really good magnifying glass?
It would have taken 20 seconds just to walk in the door. Then he's attributing his knowledge of "which book to look in" to the library, when that was his - some of us have no clue that Whos Who would tell you what books someone has written.
He's vastly understating the time it takes to use the library, probably quoting the time it took once he had the book in his hand. If you factor in having to discover which book(s) to look in and actually walking over to the shelf to find it, the library could and would take a lot longer.
You're right, my maths is bad - it overestimates the danger.
However, my point doesn't I think that most password rules don't force people out of the subset. If someone is going to pick a weak password without the rules then they will still pick a weak password with the rules. Instead of "password", a user might use "password1" - which probably passes the software enforced rules but is also probably in most dictionaries.
Yeah, it's going to take longer to search for all simple variations on a dictionary word, but it's still cheaper and faster than doing a brute force attack.
The maths used gives the theoretical number of combinations, yet you yourself guess that 90% of the population are going to base their choice on some miniscule subset of those possible.
You're being too simplistic about it. Do not get your password checking algorithm to do anything except require a certain length (and there are arguments against that), allow the users to enter whatever they like. Imposing software rules in the password generation just weakens your security.
Instead, try this: once they enter their password, run it through a decent, up to date cracking algorithm with a good dictionary.
If you find anything, alert the user that they have a weak password. If your users ignore your password requirements, start disabling their accounts.
It might seem like it only causes a 0.0005% reduction but it's a much much larger fraction.
For example, assuming a 101 keystroke keyboard (being nice and letting you put F keys and other non-printing characters in your password). For a password of length 8, the number of combinations is something like:
101 * 101 * 101 * 101 * 101 * 101 * 101 * 101 = 10,828,567,056,280,801
If you constrain passwords to contain a single non-alpha, you get:
101 * 101 * 101 * 101 * 101 * 101 * 101 * (101 - 52) = 5,253,463,225,324,349.
You have reduced your keyspace by 50%.
It makes some sense, except the crackers had the same thoughts years ago. A good dictionary will not be simply a list of words. It will be a meta-list that the crack algorithm builds passwords from.
It knows that "hello" can be spelled "hello", "h4110", "He1l0" and every other variation. Good ones also will do things like adding a single non-alpha to the end and try combinations of two or more words separated by a non-alpha. A half way decent cracking algorithm will get "H3l10&W0r1D". Don't be surprised if they also get "G2k`9^Q9e`S" and "J4;2-*E-t;F" - both those are also variants on "Hello World".
Sorry, but "y311ow" is almost as weak as "yellow". "jack4betty" is better, but still not good.
You think I'm wrong because you do not understand my argument. You sound like someone who has coded a password routine and are defending yourself.
Get this straight: imposing a minimum length on passwords is not a bad password constraint and should be the only one used as it does not reduce the key space significantly. You are incorrect to argue that there is no reduction as that is simply not true.
Imposing additional rules, such as insisting on an non-alpha significantly reduce the key space. For a password of any given length, if you know at least one character must belong to a subset of the allowable characters, then simply have less work to do.
A very simple example that even you should understand:
You have red balls and green balls. All possible sequences of balls of length two:
GG,GR,RG,RR.
If you insist on at least one character being a subset (must be green) you reduce your key space to:
GG,GR,RG.
Searching the reduced key space is less work.
Er, I guess you're just a troll, but what the hell, I've got ten minutes before I have to leave.
Let's assume you have two passwords, X and Y. X and Y both meet some arbitary password constraints.
You also have a dictionary, D1 of 1000 entries.
Let's further assume that X is in the dictionary and Y isn't.
Now, remove all entries from the dictionary that do not meet the password constraints in use giving dictionary D2.
To search the dictionary for X will now take 83% of the time and you WILL find it. The probability of is THE SAME as it was before you reduced the dictionary because the probability of X being one of the removed entries is 0.
To search the dictionary for Y will also take 83% of the time and you WON'T find it. You have again saved time because you were going to do the dictionary attack anyway, but you now finish earlier.
Now you get to do a brute force search for Y and AGAIN, the key space is reduced because you do NOT need to generate/check passwords that do not meet the rules. The brute force attack is shorter because you don't need to check some stuff.
Example: rule: passwords must be at least 2 characters and must include a non alpha.
Given: We're only using 2 character passwords.
Using simple maths and 101 possible key strokes: 101 * (101 - 52) possible entries, is 4949.
No constraints: 101 * 101 + 101 is 10302.
With constraints you have to check less than half the unconstrained set.
And the same users that pick stupid passwords with no constraints are the same users that pick stupid passwords with some alpha shoved in it because the software insists on it.
If you really want a piece of software to eliminate bad passwords, just run some crack utility on your own password file and notify users with ones that turn up.
...
Your initial attack is a dictionary attack. You eliminate passwords from the dictionary that do not meet the rules for the password you are trying to break. This means that IF the dictionary attack was going to succeed, you now succeed sooner.
If the dictionary attack fails, you then do the brute force attack which simply searches the full key space, which has been reduced by the constraints on the password.
Software enforced password constraints cause low hanging fruit to hang lower.
Google is your friend
Explained
The number of unconstrained passwords of 9 characters or less would then be: 98,815,257,325,206. No?
Because you don't have to check anything with 5 or less, you reduce the key space to 98,814,936,052,800 combinations, the number you give.
This is less work. Not much, granted, but it's still less. Anything that reduces the key space only needs to be coded into the cracking routines once to achieve that reduction in work every time.
Yup. The length being constrained to greater than some number (typically 6 or 8) characters is about the only password constraint that makes sense some kind of sense, but still - any reduction in keyspace means less work.
Assuming we take the example of the guy who had the 5 byte password that takes 18 days to crack, 1.9% still saves you 8 hours. Not an unuseful amount of time.
It's the daft "must include an non-alpha" and "must start with an alpha (or worse, a capital)" and other brain dead, crack smoking, glue sniffing password "rules" that are the real killers
98814936052800 minus 321272406 is some larger than 98814936052800?
Sir, you are a savant.
Thank you for enlightening me to a definition of "minus" that I was not aware of.
If you were thinking clearly, you would start your attack with a dictionary that you could prune based on known password rules.
Er, no? Most "password etiquette" schemes are a complete crock. Generally all they do is reduce the key space and therefore make the passwords easier to brute force attack.
You must have a password of at least 6 characters? Well, there goes everything 5 characters and less - don't have to check those.
Hmm, and while we're at it, most people are going to have a password between 6 and 9 characters, don't bother trying anything else until the second pass.
You have to have at least one non-alpha, well - I can reduce my attack to constrain my guesses around that requirement - just reduced the number of attempts necessary by 24%.
Any other rules you want to add to make attacking the password easier?
Probably the default for some piece of enterprise software that can't do it's job without creating an account to use.
Most Australians do not like Koalas much. (see my other post on this subject). They put up with them because stupid tourists pay a lot of money to be peed on.
Also, it's fun to go to a tourist trap, stand around the bottom of a tree and point up at it and walk away once the crowd gathers. Couldn't do that if the Koalas were all dead now, could we?
They sleep 14 hours a day, they are grouchy, irritable and they stink.
They have two defense mechanisms: Peeing on things and exceedingly long, tough claws.
They view many things, including being held as threatening and they are not afraid to use both defense mechanisms on short notice.
Koalas are one of the worst pets you could possibly have.
Try asking for the 3% back if you pay by cash. I once bought something for around $900 and insisted that if they didn't give me the 3% back I'd use American Express (6.4% at the time from memory)
Of course ... and if the people who buy the products can't afford to buy them any more, then the consumers will be replaced by the foreign consumers who do ... and the stockholders who sell their stock because they need an income will be replaced by foreign stockholders ... and the executives who can't see past the end of the financial year will be replaced by ones who realize that there's no such thing as a free lunch.