Which reminds me. I was once in this coffee shop that was like granola central... tons of enviro stuff with the people to match. Anyway, they had this book about trees -- the title was "HARD PINES". It just so happened to be placed upside-down on the shelf. Exercise left for the reader: write "HARD PINES" in all caps onto a sheet of paper and then turn the paper upside-down and read it. Hilarity ensues.
I know what you mean as it basically blows the whole common concept of what most people understand irony to be right out the window. Some references I've seen do describe that kind of irony but the more authoritative ones indicate that irony is when what you say has a different literal interpretation than what you mean. So if you *described* an event which had what you call situational irony, it could be ironic... but the event itself isn't. Wikipedia covers the controversy over the varying opinions.
The author of the other site I linked to argues that just because people use the word irony incorrectly and this has become popular, it doesn't make it correct. It's like asking if enough people misspelled "lose" as "loose", would the definition of the word "loose" change as a result?
Safe deposit boxes usually have dual locks that must be drilled to open if the customer misplaces the key...Which is probably mostly for show. I'm sure an experienced lockpick could easily defeat those locks without the requirement to drill them. However, they wouldn't make as much money that way and the bank/public wouldn't have as much confidence in the locks.
You mean the same rest of the world who went with the appeasement strategy when Hitler started becoming beligerent?Of course, the rest of the world was pretty sure that Hitler had weapons.
No thank you, what happens when they sell a couple of copies then go under. I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch. I don't care how fancy your wiz bang cool ui generator is, if I do not have the code it is definitely not going into my app.Right on their home page:
"BuoyBuilder(TM) is released as Open Source under the OSL license. Royalty-free, commercial licenses are available for purchase."
And exploitation? What? All people involved in whatever you are doing, have made their own choise whether to participate or not.This could be something like the paparazzi who follow around celebrities and intrude upon their lives, photographing and taking videos of their every moment not allowing them any semblance of privacy. Certainly not illegal (unfortunately) but those people all too often have not made their own choice about whether or not to participate. In my books, that qualifies as exploitation.
As you increase the number of digits on any given character you also increase the possibility of false matches. For example, if each character had all ten digits on them, you could enter any combination of the right length to login since any number you enter would match every character (ignoring the fact that it's random so you wouldn't be guaranteed each digit only once, but you get the idea).Bah... I'm on crack. Of course, you're only choosing one position out of the ten... not that all ten numbers are in the same position. With ten positions, you're looking at 40 observations. Extending the existing system to eight compass positions, for example, it would take an average 19 observations to deduce the password. Why not just go all-out and make each character into an analog clock. Instead of choosing a corner (eg: upper-right) you could choose a time (eg: 7 o'clock) and enter the number at that position. You'd have to have an average of almost 50 observations to deduce the password in that case. If this were for an online banking system, you could require a password change every three months and it would still be sufficient. Naturally, you'd want the user to have to go to their bank to change the password because if their system is keylogged then setting the password in the first place instantly compromises it.
No shit bro... stick it to da man! I remember back in fucking '91 when I emailed Linus asking him how to install his new 0.2 Linux operating system. That puppy fit on a floppy disk and it was FAST. These days you're lucky if that bloated piece of crap can get squeezed onto a CDROM since those tools in Open Source land have forced us to keep upgrading our computers. And I'm sick of these distros telling me it's my problem that their software runs like a dog circumnavigating the Martian equator after I install it (the software, not the dog) on my 386DX-66.
Bullshit, all the cell phones on the planet could fit in 200 cubic feet of space, they are just trying to scam money from lucrative industries.Are you sure that all the cell phones in the world can fit inside a cube 2 meters on a side?
So you're saying that the latest episode of Lost is your culture, and that you owned Lost before they misappropriated it from you and are now selling you what is rightfully yours? How about you go and *live* your culture and not rely on stupid TV shows instead?
Well, we agree on a few points. Most online sites (heck, even the bank I deal with) uses a regular password to login that, if keylogged, would be instantly compromised. Fortunately, about all they can do is pay my bills or transfer money between my accounts. Anything beyond that (eg: setting up payment/transfer to an account that isn't mine) typically involves either a phone call, where I can supply additional credentials, or a trip to the bank. So in that case, your Grid system is preferable when using untrusted computers if I go with the understanding that I shouldn't login multiple times from the same location.
In your example where you have to add a modifier (eg: 5 plus modifier of 2 = 7) I'm not convinced that increases the number of observations required. If anything, it requires up to ten times the amount of work as you need to keep track of ten variations but since each number is being offset by the same amount, you shouldn't need more samples than you otherwise would. Absent of decoy numbers, it would still require an average of five observations.
I'd be interested if you wanted to put up a challenge as I alluded to in a reply to uhlume. Setup the system with a strong password and some numeric modifier. Upload ten screenshots showing the grid configuration and the number you would have entered for each. I'll see how many images it takes for me to guess what the original password was. Then do the same but using decoy digits. Even if it turns out I can deduce the password in five attempts, it's better than having a keylogger grab the password in one observation... but I'm just curious how it would impact security. I suppose I could also use your online demo and simulate this myself, which I may do anyways... but it'd be more fun not knowing the password in advance.:)
Your logic might hold true if each letter corresponded to one and only one randomly-generated number. Remember, though, that the cracker doesn't know which of the four random numbers associated with each character is significant.Read again -- I take this into consideration. The odds that one corner of a given character contains the number in question is 1 in 10. There are four corners, so the odds that the number in question is on a particular character is 4 in 10, or 40%. My analysis is unchanged.
Coupled with the ability to inject "decoy digits" into the stream, I'd have to consider this system sufficiently difficult to compromise.I'd have to think about this a little more, but my initial impression is that the decoy digits don't significantly increase the difficulty of attack. However, I'm not certain on this point so I'm willing to be corrected. What I'd love to do is for someone at Grid (or yourself if you have access to a live online demo) to post a challenge for me. Choose a lengthy password of any combination of letters and numbers. Then post a screenshot of the grid configuration including the numeric password you would enter. Do this, say, ten times for the same password. Upload the files somewhere, call them grid01.png to grid10.png, and I'll decode them, explaining my work, and see how many images it takes before I can guess the correct password. If I'm right, I'll only have to use up to grid05.png to decode your password. As an interesting comparison, do this both with and without decoy numbers as I'm curious how much extra complexity would be introduced by the decoys.
If you really wanted to complicate things, you could use a hex-based grid (for six associated numbers instead of four), or use a combination of one-, two- and even three-digit key numbers (thus conferring uncertainty as to how many characters in the sequence each numeral corresponds).As you increase the number of digits on any given character you also increase the possibility of false matches. For example, if each character had all ten digits on them, you could enter any combination of the right length to login since any number you enter would match every character (ignoring the fact that it's random so you wouldn't be guaranteed each digit only once, but you get the idea). Whether multiple numbers per corner would significantly increase the difficulty of attack, I'm not sure. It'd make it more tedious to solve, but I'm not certain it would require significantly more observations. However, from their explanation it didn't appear this was a feature of the system.
Naturally, there are tradeoffs involved between security and convenience, and I'd probably want to use a system like this in conjunction with one or more additional factors, perhaps managed by a risk-based evaluation system.I fully agree on that point.
On the other hand, this system is easily as secure, if not more secure, than many considerably more inconvenient systems that I've evaluated, and that's worth quite a lot in the real world of online banking, where we often find it necessary to balance security with ease of use (always erring in favor of security, of course).
(In case you were wondering, I have no affiliation with GDS, nor any particular intention of deploying their GridOne system, but I do work for a financial institution which is currently in the process of evaluating a number of similar products, and their approach struck me as notably clever.)It's clever enough, but do the math before implementing. And again, as a solution for travelers who need to login once per location, it does provide sufficient security to make it worthwhile in combination with account timeout periods for multiple unsuccessful login attempts. But for defeating key/screen capture trojans installed on a user's home/work machine, it doesn't provide for much security.
Regarding brute force. Let's not confuse brute forcing a static/reusable password with a one time password (OTP). Static in NON-linear and the OTP nature of GridOne creates linear security. There is nothing to bruteforce with an OTP. Also normal account/system lock out defetas any type of guessing of automated attacks.I agree that you can't brute-force a one-time password. However, as I pointed out in my other reply, your system is not a one-time password since each attempt is derived from a static password by elementary transformations which, over the course of observing several logins, can be trivially decoded. Once I've observed the same user logging in five times using your system, I can easily login without having to guess at the password and triggering a lockout. It's good enough if the attacker can only observe one login, but if a key/screen capture trojan is installed on the user's home or work machine for example, it offers little protection.
Nac-The GridOne system and its patented approach allow for greater security through the use of Decoys(TM) or Decoy Digits(TM).Upon login the user simple keys in (anywhere in the actual GridCode sequence) any arbitrarily selected, extra numbers or Decoy Digits(TM) and injects them into their strand of numbers So if the real GridCode answer is 51832, the user can enter 3518932; the Decoys of a 3 and 9 are added. Now you are the attacker, and not knowing what are real and what are Decoys(TM), what is the user's underlying GridPass(TM)/password???That doesn't matter. Again, after observing several logins any decoy numbers will not matter. They too will be canceled out after you eliminate the possibilities.
This extremely simple, yet highly effective security feature will confer excellent security upon login and will force the opportunistic attack to become a concerted attack requiring time, opportunity and resources.I agree that it is extremely simple. However, it's not that great of a security feature if the user is required to login multiple times from the same location.
Grid allows and delivers the unparalleled, proven security delivered by One Time Passwords without the need of any device, extra materials, computer modifications or time synchronization (exposed to possible reply attacks).This is much better in that circumstance if you place the constraint that no other security options are available. X.509 certificates through a device, or even *real* one-time passwords would be infinitely preferable. A true one-time password is not based upon any outside information but is rather a completely randomly generated list of passwords that can be used only once. Calling your Grid system a one-time password is misleading in the general case. The problem with your implementation is that the so-called one-time password isn't random but is derived from an actual password through a simple transformation. This completely eliminates the inherent security offered by real one-time passwords. A real one-time password system is completely unbreakable even after a million observations. Your system is breakable in only five. Quite the difference.
Grid allows users to customize their own log-in interface to ensure they are logging into the proper site and that they are authenticating to the true GridCore(TM) server.This is no different than any other site that uses SSL. Without SSL, your Grid system is as vulnerable to man-in-the-middle as any other one, with the exception that it takes about five observations to derive the password instead of one.
Again, from any computer, from anywhere while raising the bar against phishing attacks.The other methods? 1 single casual observation , being shoulder-surfed or being watched as the users logs in (getting all the information and/or images), and the user's account is compromised at that instance. Ask most other authentication systems if you can "see or have everything at login" and what will their security be?Nothing is bomb-proof, but GridOne allows complete portability and untethered, secure access from any machine from anywhere, nothing to ship, mail, print, download or carry for the end users or their machines.If you can restrict your logins to only once per location, then I'll agree with your assertion that the security is "good enough" for casual use. However, this article concerns trojan keystroke/screencap loggers being installed on someone's computer surreptitiously. Assuming they trust their own computer, if they login from it five times in a row using your Grid system, an attacker will have compromised the password... regardless of any decoy schemes employed.
Just thinking about this further, it gets even worse. Assuming you know the background behind the system (where the user specified in advance to use the same unknown corner each time) then you can also improve by eliminating corners. It's too late to do the math on that as well, but you can probably shave off one or two observations by incorporating that strategy.
Really? Care to explain how that works when the corresponding numbers change with each login?I'm assuming the attacker has a screenshot of the grid with the letters and numbers for each time and that the password doesn't change. Each of the 62 characters (A-Z, a-z, 0-9) has 4 numbers out of 10. So there's a 40% chance that a given number is on any of the characters. This means that, on average, 40% of the characters have that number. Rounding up each time, that's 25 possible matching characters for each character of the first login. After observing the second login, there's a 40% chance that each of those remaining 25 characters contain the new number as well. We've narrowed it down to 10 characters. Keep going with this methodology and on the third try, we're down to 4 characters. On the fourth try, that's 2 characters. And on the fifth try we should have the character. You can do this for all characters of the password simultaneously.
So, assuming the password remains the same, it will take on average five observations of the user entering the same password before you've cracked it. It doesn't matter how random, complex, or long the password is. Nor does it matter if you include all of the symbol characters as well. Five observations will get it using their system. Of course, that's better than getting it in only one observation... but not much.
Since the numbers are randomly generated with each display of the entry grid, and any numeral may appear in multiple places on a given random grid, this effectively defeats both keyloggers and screengrabbers: even if you can see both the entry grid and the entered keystrokes, deriving the user's password from that information is non-trivial.Unless you observe multiple logins, in which case matching up which numbers correspond to which letters becomes nothing more than a game of MasterMind.
That's a remarkably elegant system which (depending on how you establish the password) pretty much defeats any kind of screen scraping technology.Unfortunately it doesn't defeat brute force attempts but rather helps them. In their example, the password is "Grid1" which if we assume the available characters are 0-9, A-Z, and a-z results in a possible 62^5 possible permutations. Replacing the characters with numbers results in the password having only the characters 0-9 which results in a possible 10^5 permutations -- almost 10,000 times weaker. I suppose that's yet another demonstration that security boils down to a series of trade-offs.
Slashdot Mirror
I suppose Alanis Morissette would say that it's like right after you get a free ticket to the amusement park, the ferrous wheel shuts down.
Which reminds me. I was once in this coffee shop that was like granola central... tons of enviro stuff with the people to match. Anyway, they had this book about trees -- the title was "HARD PINES". It just so happened to be placed upside-down on the shelf. Exercise left for the reader: write "HARD PINES" in all caps onto a sheet of paper and then turn the paper upside-down and read it. Hilarity ensues.
I know what you mean as it basically blows the whole common concept of what most people understand irony to be right out the window. Some references I've seen do describe that kind of irony but the more authoritative ones indicate that irony is when what you say has a different literal interpretation than what you mean. So if you *described* an event which had what you call situational irony, it could be ironic... but the event itself isn't. Wikipedia covers the controversy over the varying opinions.
The author of the other site I linked to argues that just because people use the word irony incorrectly and this has become popular, it doesn't make it correct. It's like asking if enough people misspelled "lose" as "loose", would the definition of the word "loose" change as a result?
Safe deposit boxes usually have dual locks that must be drilled to open if the customer misplaces the key...Which is probably mostly for show. I'm sure an experienced lockpick could easily defeat those locks without the requirement to drill them. However, they wouldn't make as much money that way and the bank/public wouldn't have as much confidence in the locks.
You keep using that word. I don't think it means what you think it means.
It's really nice to see Wiki software used for it's original purpose, and used properly.Unfortunately I can't edit your post to correct the typo.
UK, Australia, Japan, South Korea, Taiwan, most of Eastern Europe, Spain, Italy.Glad to see you didn't forget Poland.
You mean the same rest of the world who went with the appeasement strategy when Hitler started becoming beligerent?Of course, the rest of the world was pretty sure that Hitler had weapons.
No thank you, what happens when they sell a couple of copies then go under. I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch. I don't care how fancy your wiz bang cool ui generator is, if I do not have the code it is definitely not going into my app.Right on their home page:
r c-1.1.zip
"BuoyBuilder(TM) is released as Open Source under the OSL license. Royalty-free, commercial licenses are available for purchase."
http://buoybuilder.com/DownloadData/BuoyBuilder-s
"from the jokes-that-some-people-just-wont-get dept."
And exploitation? What? All people involved in whatever you are doing, have made their own choise whether to participate or not.This could be something like the paparazzi who follow around celebrities and intrude upon their lives, photographing and taking videos of their every moment not allowing them any semblance of privacy. Certainly not illegal (unfortunately) but those people all too often have not made their own choice about whether or not to participate. In my books, that qualifies as exploitation.
As you increase the number of digits on any given character you also increase the possibility of false matches. For example, if each character had all ten digits on them, you could enter any combination of the right length to login since any number you enter would match every character (ignoring the fact that it's random so you wouldn't be guaranteed each digit only once, but you get the idea).Bah... I'm on crack. Of course, you're only choosing one position out of the ten... not that all ten numbers are in the same position. With ten positions, you're looking at 40 observations. Extending the existing system to eight compass positions, for example, it would take an average 19 observations to deduce the password. Why not just go all-out and make each character into an analog clock. Instead of choosing a corner (eg: upper-right) you could choose a time (eg: 7 o'clock) and enter the number at that position. You'd have to have an average of almost 50 observations to deduce the password in that case. If this were for an online banking system, you could require a password change every three months and it would still be sufficient. Naturally, you'd want the user to have to go to their bank to change the password because if their system is keylogged then setting the password in the first place instantly compromises it.
No shit bro... stick it to da man! I remember back in fucking '91 when I emailed Linus asking him how to install his new 0.2 Linux operating system. That puppy fit on a floppy disk and it was FAST. These days you're lucky if that bloated piece of crap can get squeezed onto a CDROM since those tools in Open Source land have forced us to keep upgrading our computers. And I'm sick of these distros telling me it's my problem that their software runs like a dog circumnavigating the Martian equator after I install it (the software, not the dog) on my 386DX-66.
Bullshit, all the cell phones on the planet could fit in 200 cubic feet of space, they are just trying to scam money from lucrative industries.Are you sure that all the cell phones in the world can fit inside a cube 2 meters on a side?
They steal our culture and sell it back to us...
So you're saying that the latest episode of Lost is your culture, and that you owned Lost before they misappropriated it from you and are now selling you what is rightfully yours? How about you go and *live* your culture and not rely on stupid TV shows instead?
Well, we agree on a few points. Most online sites (heck, even the bank I deal with) uses a regular password to login that, if keylogged, would be instantly compromised. Fortunately, about all they can do is pay my bills or transfer money between my accounts. Anything beyond that (eg: setting up payment/transfer to an account that isn't mine) typically involves either a phone call, where I can supply additional credentials, or a trip to the bank. So in that case, your Grid system is preferable when using untrusted computers if I go with the understanding that I shouldn't login multiple times from the same location.
:)
In your example where you have to add a modifier (eg: 5 plus modifier of 2 = 7) I'm not convinced that increases the number of observations required. If anything, it requires up to ten times the amount of work as you need to keep track of ten variations but since each number is being offset by the same amount, you shouldn't need more samples than you otherwise would. Absent of decoy numbers, it would still require an average of five observations.
I'd be interested if you wanted to put up a challenge as I alluded to in a reply to uhlume. Setup the system with a strong password and some numeric modifier. Upload ten screenshots showing the grid configuration and the number you would have entered for each. I'll see how many images it takes for me to guess what the original password was. Then do the same but using decoy digits. Even if it turns out I can deduce the password in five attempts, it's better than having a keylogger grab the password in one observation... but I'm just curious how it would impact security. I suppose I could also use your online demo and simulate this myself, which I may do anyways... but it'd be more fun not knowing the password in advance.
Your logic might hold true if each letter corresponded to one and only one randomly-generated number. Remember, though, that the cracker doesn't know which of the four random numbers associated with each character is significant.Read again -- I take this into consideration. The odds that one corner of a given character contains the number in question is 1 in 10. There are four corners, so the odds that the number in question is on a particular character is 4 in 10, or 40%. My analysis is unchanged. Coupled with the ability to inject "decoy digits" into the stream, I'd have to consider this system sufficiently difficult to compromise.I'd have to think about this a little more, but my initial impression is that the decoy digits don't significantly increase the difficulty of attack. However, I'm not certain on this point so I'm willing to be corrected. What I'd love to do is for someone at Grid (or yourself if you have access to a live online demo) to post a challenge for me. Choose a lengthy password of any combination of letters and numbers. Then post a screenshot of the grid configuration including the numeric password you would enter. Do this, say, ten times for the same password. Upload the files somewhere, call them grid01.png to grid10.png, and I'll decode them, explaining my work, and see how many images it takes before I can guess the correct password. If I'm right, I'll only have to use up to grid05.png to decode your password. As an interesting comparison, do this both with and without decoy numbers as I'm curious how much extra complexity would be introduced by the decoys. If you really wanted to complicate things, you could use a hex-based grid (for six associated numbers instead of four), or use a combination of one-, two- and even three-digit key numbers (thus conferring uncertainty as to how many characters in the sequence each numeral corresponds).As you increase the number of digits on any given character you also increase the possibility of false matches. For example, if each character had all ten digits on them, you could enter any combination of the right length to login since any number you enter would match every character (ignoring the fact that it's random so you wouldn't be guaranteed each digit only once, but you get the idea). Whether multiple numbers per corner would significantly increase the difficulty of attack, I'm not sure. It'd make it more tedious to solve, but I'm not certain it would require significantly more observations. However, from their explanation it didn't appear this was a feature of the system. Naturally, there are tradeoffs involved between security and convenience, and I'd probably want to use a system like this in conjunction with one or more additional factors, perhaps managed by a risk-based evaluation system.I fully agree on that point. On the other hand, this system is easily as secure, if not more secure, than many considerably more inconvenient systems that I've evaluated, and that's worth quite a lot in the real world of online banking, where we often find it necessary to balance security with ease of use (always erring in favor of security, of course).
(In case you were wondering, I have no affiliation with GDS, nor any particular intention of deploying their GridOne system, but I do work for a financial institution which is currently in the process of evaluating a number of similar products, and their approach struck me as notably clever.)It's clever enough, but do the math before implementing. And again, as a solution for travelers who need to login once per location, it does provide sufficient security to make it worthwhile in combination with account timeout periods for multiple unsuccessful login attempts. But for defeating key/screen capture trojans installed on a user's home/work machine, it doesn't provide for much security.
Regarding brute force. Let's not confuse brute forcing a static/reusable password with a one time password (OTP). Static in NON-linear and the OTP nature of GridOne creates linear security. There is nothing to bruteforce with an OTP. Also normal account/system lock out defetas any type of guessing of automated attacks.I agree that you can't brute-force a one-time password. However, as I pointed out in my other reply, your system is not a one-time password since each attempt is derived from a static password by elementary transformations which, over the course of observing several logins, can be trivially decoded. Once I've observed the same user logging in five times using your system, I can easily login without having to guess at the password and triggering a lockout. It's good enough if the attacker can only observe one login, but if a key/screen capture trojan is installed on the user's home or work machine for example, it offers little protection.
Nac-The GridOne system and its patented approach allow for greater security through the use of Decoys(TM) or Decoy Digits(TM).Upon login the user simple keys in (anywhere in the actual GridCode sequence) any arbitrarily selected, extra numbers or Decoy Digits(TM) and injects them into their strand of numbers So if the real GridCode answer is 51832, the user can enter 3518932; the Decoys of a 3 and 9 are added. Now you are the attacker, and not knowing what are real and what are Decoys(TM), what is the user's underlying GridPass(TM)/password???That doesn't matter. Again, after observing several logins any decoy numbers will not matter. They too will be canceled out after you eliminate the possibilities. This extremely simple, yet highly effective security feature will confer excellent security upon login and will force the opportunistic attack to become a concerted attack requiring time, opportunity and resources.I agree that it is extremely simple. However, it's not that great of a security feature if the user is required to login multiple times from the same location. Grid allows and delivers the unparalleled, proven security delivered by One Time Passwords without the need of any device, extra materials, computer modifications or time synchronization (exposed to possible reply attacks).This is much better in that circumstance if you place the constraint that no other security options are available. X.509 certificates through a device, or even *real* one-time passwords would be infinitely preferable. A true one-time password is not based upon any outside information but is rather a completely randomly generated list of passwords that can be used only once. Calling your Grid system a one-time password is misleading in the general case. The problem with your implementation is that the so-called one-time password isn't random but is derived from an actual password through a simple transformation. This completely eliminates the inherent security offered by real one-time passwords. A real one-time password system is completely unbreakable even after a million observations. Your system is breakable in only five. Quite the difference. Grid allows users to customize their own log-in interface to ensure they are logging into the proper site and that they are authenticating to the true GridCore(TM) server.This is no different than any other site that uses SSL. Without SSL, your Grid system is as vulnerable to man-in-the-middle as any other one, with the exception that it takes about five observations to derive the password instead of one. Again, from any computer, from anywhere while raising the bar against phishing attacks.The other methods? 1 single casual observation , being shoulder-surfed or being watched as the users logs in (getting all the information and/or images), and the user's account is compromised at that instance. Ask most other authentication systems if you can "see or have everything at login" and what will their security be?Nothing is bomb-proof, but GridOne allows complete portability and untethered, secure access from any machine from anywhere, nothing to ship, mail, print, download or carry for the end users or their machines.If you can restrict your logins to only once per location, then I'll agree with your assertion that the security is "good enough" for casual use. However, this article concerns trojan keystroke/screencap loggers being installed on someone's computer surreptitiously. Assuming they trust their own computer, if they login from it five times in a row using your Grid system, an attacker will have compromised the password... regardless of any decoy schemes employed.
Just thinking about this further, it gets even worse. Assuming you know the background behind the system (where the user specified in advance to use the same unknown corner each time) then you can also improve by eliminating corners. It's too late to do the math on that as well, but you can probably shave off one or two observations by incorporating that strategy.
Really? Care to explain how that works when the corresponding numbers change with each login?I'm assuming the attacker has a screenshot of the grid with the letters and numbers for each time and that the password doesn't change. Each of the 62 characters (A-Z, a-z, 0-9) has 4 numbers out of 10. So there's a 40% chance that a given number is on any of the characters. This means that, on average, 40% of the characters have that number. Rounding up each time, that's 25 possible matching characters for each character of the first login. After observing the second login, there's a 40% chance that each of those remaining 25 characters contain the new number as well. We've narrowed it down to 10 characters. Keep going with this methodology and on the third try, we're down to 4 characters. On the fourth try, that's 2 characters. And on the fifth try we should have the character. You can do this for all characters of the password simultaneously.
So, assuming the password remains the same, it will take on average five observations of the user entering the same password before you've cracked it. It doesn't matter how random, complex, or long the password is. Nor does it matter if you include all of the symbol characters as well. Five observations will get it using their system. Of course, that's better than getting it in only one observation... but not much.
Since the numbers are randomly generated with each display of the entry grid, and any numeral may appear in multiple places on a given random grid, this effectively defeats both keyloggers and screengrabbers: even if you can see both the entry grid and the entered keystrokes, deriving the user's password from that information is non-trivial.Unless you observe multiple logins, in which case matching up which numbers correspond to which letters becomes nothing more than a game of MasterMind.
That's a remarkably elegant system which (depending on how you establish the password) pretty much defeats any kind of screen scraping technology.Unfortunately it doesn't defeat brute force attempts but rather helps them. In their example, the password is "Grid1" which if we assume the available characters are 0-9, A-Z, and a-z results in a possible 62^5 possible permutations. Replacing the characters with numbers results in the password having only the characters 0-9 which results in a possible 10^5 permutations -- almost 10,000 times weaker. I suppose that's yet another demonstration that security boils down to a series of trade-offs.
In Korea, this only affects old Sebastians.
I see a red door and I want it femtoblasted black....nope, you're right, doesn't scan.With a slight modification, it's somewhat catchy:
"I see a red door and I want it femto black..."