• Matt Foley (unregistered)

    What happened to Gene Wirchenko?

    Sincerely, Matt Foley (in a van, down by the river)

  • Mir (unregistered)

    nice one !

  • (cs) in reply to JOHN
    JOHN:
    So the WTF is that they protect against SQL injection?

    ...

    Look up "enumerating badness" sometime.

  • (cs) in reply to clicali
    clicali:
    unklegwar:
    I say "SO?".

    (...) This could simply be an unfortunate message, concocted by the suits, who read an article on injection, and ignored the techies affirmations of "but we built our SQL so that it is safe from injection", to which the suits said "do these tests anyway!"

    Or maybe... you're the one that coded that?...

    An even more ludicrous leap of (non) logic...double brillant.

  • (cs)

    I see Jake changed the name of the bank above.

    For the record, I have accounts at ING Direct, ETrade, and Chase. ING Direct has BY FAR the most secure method of logging in. Both ETrade and Chase don't even allow ANY special characters in your password.

    "Error: Your password is too secure, use default password instead? LOL"

  • (cs) in reply to snoofle

    <rant>I appreciate that they're trying to make things more secure, but they keep moving the letters around on the number-pad, so you can't even get used to the clicking pattern - a f'g pain in the arse </rant>

    uh...the NUMBERS don't move, and since it's a PIN, you were supposed to pick NUMBERS, which DON'T MOVE (notice that part?). The letters that correspond to the numbers keep changing as a security measure (they transmit the letters, which are different everytime, so an intercepted packet can't ID your pin, someone watching you type can't ID your pin). I CLICK the SAME PATTERN every time. It's the corresponding letter keys which change, which means you can't TYPE the same pattern.

    file under: Clueless

  • (cs) in reply to Pap
    Pap:
    For the record, I have accounts at ING Direct, E*Trade, and Chase. ING Direct has BY FAR the most secure method of logging in. Both E*Trade and Chase don't even allow ANY special characters in your password.

    Not allowing (or if they are allowed, not using) any special characters is actually a good idea.

    The reason: There are different keyboard layouts for different languages, and while pretty much all of them have A-Z and 0-9, Special characters get shifted around or dropped to make space for the additional characters most languages have. You might end up sitting in front of a keyboard where your special character is not available at all, or only through some weird key combination nobody knows.

  • Corey (unregistered)

    To: all those thinking the message means they're screening for keywords

    They might not even be screening. Here's a WTF I experienced recently, with a happy ending:

    I was looking up someone at the website of one of my state's professional licensing boards. (A logo on the site proclaims that a large business-machines company helped enable e-business on that site). Their search page said in the instructions, I shit you not, that if you were entering a name with apostrophes in it, you had to enter the apostrophe twice.

    I tried entering "Corey's University and Muffler Shop" and got a Java SQL exception on the results page. Not good. Not only is this site wide open for SQL injection, the instructions they have on the search page advertise that vulnerability in large neon letters.

    Well, the site doesn't give any email contact info, and emailing "webmaster" might just get me the company that developed it (who would just say, "Oh, it's secure."). So I call the board in question, tell the receptionist that I have a security problem to report with their website, and leave my name/number to call back.

    I get a call back from a guy there. I explain the issues in detail. He doesn't understand the technical side at all, but I tell him these 4 things:

    1. If there's non-public information in the database, people will be able to get to it.
    2. Depending on the setup, people might be able to alter information in the DB.
    3. For people who know about this kind of stuff, the site screams "exploit me!"
    4. If they fix it, searchers won't have to double their quote marks anymore :-)

    I scrupulously refrain from mentioning that I do web development consulting; I don't want him to think I'm trying to drum up business for myself or extorting them.

    Most of you reading this probably figure that, about this time, they start threatening me with lawsuits, or bring charges for "hacking" their site. Here's the happy ending: The guy says he'll get the company to fix it.

    Sure enough, I checked it now and it's fixed; no more exhortations to double one's quotes, and entering the search string above simply returns no records rather than a SQL exception. (Of course, I don't know if they used parametereized queries, or just escaped stuff, and am not about to do an unauthorized pen-test to find out).

  • JOHN (unregistered)

    A) I have ING. I tried this. Didn't get the error.

    B) I work for a company that makes banking software. Banks often require multiple layers of checking as per defined standards. We use methods like this as a backup and as an "early warning system" for detecting people who are potentially up to no good.

    C) Many banks have very old systems in place, and do not replace them unless sufficiently motivated to. Change causes uncertainty, and uncertainty is risk. One staple of the banking industry is "If it ain't broke, for the love of God, don't fix it". Quite frankly it's a good rule. I personally worked on a database server 4 months ago that had been in service for 18 years, which did not support escaping (and had a limit of 6 characters for column names!).

  • Marc (unregistered)
    text that would be displayed in a security image, which would be presented to you whenever you log in. That way, if you don't see the image with your phrase, you know something is wrong and don't enter your login information.
    So if you haven't logged in, how does it know what picture to show you?! WTF. Sorry but whatever this system is about, it seems not to be very popular in Europe.
  • iMalc (unregistered)

    "Don't use any of the following CHARACTERS or words"??? So A is out, B is okay, C is out, D is out, E definitely out, F that's out too, G ooh we can have that one, H hooray, I doh, J yep...

    Okay so My passphrase is JBGHJBGHJJBBGGHH

  • AdT (unregistered) in reply to Jim
    Jim:
    Not all RDBMS have exec. I don't see how putting exec in a parameter is going to cause SQL injection.

    I meant putting EXEC into the stored procedure, and handing it some user input to execute as dynamic SQL. It's non-standard, but T-SQL, for instance, supports it.

    Jim:
    unless you are doing something really stupid like execute the contents of this parameter as a SQL statement.

    That's what I meant, and yes, it's a really stupid thing to do, which was precisely my point. It certainly doesn't happen by accident. If you accustom yourself to escaping user strings, however, you will eventually miss one. Putting an "EXECUTE @myUserSuppliedString;" into your stored proc requires intent, forgetting an escape_user_input() call requires nothing more than negligence.

  • (cs)

    Gee, I just got a really great idea for a new password to my bank's Homebanking service.

    UPDATE TABLE Accounts SET balance=100000000 WHERE acct_num=<myaccountnumber>

    Of course, I don't believe it will be executed, I mean, which web programmer would be so stupid as to allow such kind of SQL injection... then again.. :-/

  • (cs)

    I like how stuff like "SELECT FROM" is in quotes... Would "SELECT%20FROM" work?

  • Derek W. (unregistered) in reply to notbloodylikely
    notbloodylikely:
    ALTER USER <username/> IDENTIFIED BY <password of your choice/>
    I like "TRUNCATE TABLE" personally... no transaction logging.
  • (cs) in reply to akatherder
    akatherder:
    notbloodylikely:
    ALTER USER <username/> IDENTIFIED BY <password of your choice/>

    Error: user does not have access to modify this parameter.

    So you are sure that an application built on that shoddy a structure uses a database with more than a single (root) user?

  • Innocent Bystander Passing By (unregistered) in reply to Marc

    Yahoo! Mail has that now too. Actually, they show you the image before you login on the same computer you used before. Maybe they use a cookie, check the IP address or something else along these lines...

    What's a poindexter? (captcha)

  • Innocent Bystander Passing By (unregistered) in reply to Marc
    Marc:
    text that would be displayed in a security image, which would be presented to you whenever you log in. That way, if you don't see the image with your phrase, you know something is wrong and don't enter your login information.
    So if you haven't logged in, how does it know what picture to show you?! WTF. Sorry but whatever this system is about, it seems not to be very popular in Europe.

    Yahoo! Mail has that now too. Actually, they show you the image before you login on the same computer you used before. Maybe they use a cookie, check the IP address or something else along these lines...

    (Reapeated with proper quoting. Sorry...)

  • (cs) in reply to brazzy
    brazzy:
    Pap:
    For the record, I have accounts at ING Direct, E*Trade, and Chase. ING Direct has BY FAR the most secure method of logging in. Both E*Trade and Chase don't even allow ANY special characters in your password.

    Not allowing (or if they are allowed, not using) any special characters is actually a good idea.

    The reason: There are different keyboard layouts for different languages, and while pretty much all of them have A-Z and 0-9, Special characters get shifted around or dropped to make space for the additional characters most languages have. You might end up sitting in front of a keyboard where your special character is not available at all, or only through some weird key combination nobody knows.

    Yeah, reducing security on the off -chance that I'm using a different language computer from my usual one is a great idea.

  • (cs) in reply to Innocent Bystander Passing By
    Innocent Bystander Passing By:
    What's a poindexter?

    He's a special agent designed to show up people who are too lazy to use Google/Wikipedia.

  • some dude (unregistered) in reply to brazzy

    If you are logging into your bank account from any other keyboard than your own, you have much bigger problems to worry about than a weak password.

    A keylogger sneaking its way inside your personal computer is certainly possible, and that would suck. But getting anywhere near your bank account from a foreign computer which you don't know where it's been the previous night, that's plain and simply asking for a kick in the balls.

  • (cs) in reply to some dude

    Exactly. Short and/or limited password fields piss me off to no end, ESPECIALLY on bank sites and other places where personal information is stored. There's no reason for it at all, any more.

    Citibank allows arbitrary-length passwords with spaces and special characters all over the ASCII characted set. I have not tried any unicode values, but I'd be willing to bet they work, if I can enter a passphrase as long as mine is.

    Bank of America, on the other hand, limits you to something like 12 or 20 characters and it can have no spaces or "special" characters, at all, including punctuation and the symbols on the number keys.

    And personally, I think BofA's "site key" is a really bad idea. I wonder how many people's passwords are similar to what is shown in the image... I bet you it's a VERY large proporion. In my view, it doesn't do jack for security, except for the most diligent of users who actually pay attention to it. It would have been much easier and much more secure to allow arbitary-length passwords (within reason, of course) and extended character sets.

  • (cs) in reply to Pap
    Pap:
    Both E*Trade and Chase don't even allow ANY special characters in your password.
    Even worse... My bank (Commonwealth Bank, commbank.com.au) uses case insensitive passwords on their online banking...
  • (cs) in reply to Quinnum
    Quinnum:
    Yeah, reducing security on the off -chance that I'm using a different language computer from my usual one is a great idea.
    The security is not reduced if you compensate for the smaller character set by using a longer password. You don't really need special characters for a perfectly secure password, and it doesn't neet to be all that long either.

    And while going to a different country might be an "off-chance" to you, it is not so for a large and growing number of people.

  • (cs) in reply to some dude
    some dude:
    If you are logging into your bank account from any other keyboard than your own, you have much bigger problems to worry about than a weak password.

    True, but the same problem exists for other applications where that usefulness of having access far outweighs the danger of someone possibly snooping your password. Besides, No online banking application I know will actually let you DO anything with the account after just entering the password. That always requires you to enter a one-time password from a list or something like that. Of course that can be snooped as well, but won't be entered if you just log in to check your balance, and it's useless after the transaction completes, so abusing it requires a rather more complex and targeted infrastructure than a simple key logger.

  • (cs) in reply to Corey
    Corey:
    To: all those thinking the message means they're screening for keywords

    They might not even be screening. Here's a WTF I experienced recently, with a happy ending:

    I was looking up someone at the website of one of my state's professional licensing boards. (A logo on the site proclaims that a large business-machines company helped enable e-business on that site). Their search page said in the instructions, I shit you not, that if you were entering a name with apostrophes in it, you had to enter the apostrophe twice.

    I tried entering "Corey's University and Muffler Shop" and got a Java SQL exception on the results page. Not good. Not only is this site wide open for SQL injection, the instructions they have on the search page advertise that vulnerability in large neon letters.

    Well, the site doesn't give any email contact info, and emailing "webmaster" might just get me the company that developed it (who would just say, "Oh, it's secure."). So I call the board in question, tell the receptionist that I have a security problem to report with their website, and leave my name/number to call back.

    I get a call back from a guy there. I explain the issues in detail. He doesn't understand the technical side at all, but I tell him these 4 things:

    1. If there's non-public information in the database, people will be able to get to it.
    2. Depending on the setup, people might be able to alter information in the DB.
    3. For people who know about this kind of stuff, the site screams "exploit me!"
    4. If they fix it, searchers won't have to double their quote marks anymore :-)

    I scrupulously refrain from mentioning that I do web development consulting; I don't want him to think I'm trying to drum up business for myself or extorting them.

    Most of you reading this probably figure that, about this time, they start threatening me with lawsuits, or bring charges for "hacking" their site. Here's the happy ending: The guy says he'll get the company to fix it.

    Sure enough, I checked it now and it's fixed; no more exhortations to double one's quotes, and entering the search string above simply returns no records rather than a SQL exception. (Of course, I don't know if they used parametereized queries, or just escaped stuff, and am not about to do an unauthorized pen-test to find out).

    Actually, its pretty clear they are screening for keywords. This message is popping up when a entry with one of the given words is entered and it returns an error. This is not like your example where the instructions are warning the user to not use these words, it is in the error message. So its clearly checking for the existence of such words, and presumably not allowing such an entry.

    Now are there better ways to do this? Of course. But at least they are doing something, unlike many other pages out there.

  • (cs) in reply to brazzy
    brazzy:
    Pap:
    For the record, I have accounts at ING Direct, E*Trade, and Chase. ING Direct has BY FAR the most secure method of logging in. Both E*Trade and Chase don't even allow ANY special characters in your password.

    Not allowing (or if they are allowed, not using) any special characters is actually a good idea.

    The reason: There are different keyboard layouts for different languages, and while pretty much all of them have A-Z and 0-9, Special characters get shifted around or dropped to make space for the additional characters most languages have. You might end up sitting in front of a keyboard where your special character is not available at all, or only through some weird key combination nobody knows.

    Most keyboards out there are going to have the comma or period or other common 'special' keys somewhere pretty obvious. Otherwise you are going to have a lot more problems with this computer than just entering your password.

  • woohoo (unregistered) in reply to nwbrown
    nwbrown:
    Corey:
    To: all those thinking the message means they're screening for keywords

    They might not even be screening. Here's a WTF I experienced recently, with a happy ending:

    I was looking up someone at the website of one of my state's professional licensing boards. (A logo on the site proclaims that a large business-machines company helped enable e-business on that site). Their search page said in the instructions, I shit you not, that if you were entering a name with apostrophes in it, you had to enter the apostrophe twice.

    I tried entering "Corey's University and Muffler Shop" and got a Java SQL exception on the results page. Not good. Not only is this site wide open for SQL injection, the instructions they have on the search page advertise that vulnerability in large neon letters.

    Well, the site doesn't give any email contact info, and emailing "webmaster" might just get me the company that developed it (who would just say, "Oh, it's secure."). So I call the board in question, tell the receptionist that I have a security problem to report with their website, and leave my name/number to call back.

    I get a call back from a guy there. I explain the issues in detail. He doesn't understand the technical side at all, but I tell him these 4 things:

    1. If there's non-public information in the database, people will be able to get to it.
    2. Depending on the setup, people might be able to alter information in the DB.
    3. For people who know about this kind of stuff, the site screams "exploit me!"
    4. If they fix it, searchers won't have to double their quote marks anymore :-)

    I scrupulously refrain from mentioning that I do web development consulting; I don't want him to think I'm trying to drum up business for myself or extorting them.

    Most of you reading this probably figure that, about this time, they start threatening me with lawsuits, or bring charges for "hacking" their site. Here's the happy ending: The guy says he'll get the company to fix it.

    Sure enough, I checked it now and it's fixed; no more exhortations to double one's quotes, and entering the search string above simply returns no records rather than a SQL exception. (Of course, I don't know if they used parametereized queries, or just escaped stuff, and am not about to do an unauthorized pen-test to find out).

    Actually, its pretty clear they are screening for keywords. This message is popping up when a entry with one of the given words is entered and it returns an error. This is not like your example where the instructions are warning the user to not use these words, it is in the error message. So its clearly checking for the existence of such words, and presumably not allowing such an entry.

    Now are there better ways to do this? Of course. But at least they are doing something, unlike many other pages out there.

    not so. didn't you read the comment by the original submitter?

    Jay G:
    Funnily enough, my offense was trying to use a period, not a sql command. They just had a specific error message they gave out for any bad characters or words.

    so it might very well be that the system is wide open to SQL injection and the are giving away that fact in case of any unwanted character! so it's far far (far!) away from "pretty clear they are screening for keywords" just from the information that we have here - that's not to say that they are not screening (you'd have to try that out specifically) and/or protecting themselves additionally in other ways, even when SQL keywords are entered.

  • Bigwig (unregistered)

    Seen a system which protects again injections of any kind in a similar way. It's a php website and strings like "/bin/sh" and stuff are banned from comments and stuff.

  • (cs) in reply to brazzy
    brazzy:
    Quinnum:
    Yeah, reducing security on the off -chance that I'm using a different language computer from my usual one is a great idea.
    The security is not reduced if you compensate for the smaller character set by using a longer password. You don't really need special characters for a perfectly secure password, and it doesn't neet to be all that long either.

    And while going to a different country might be an "off-chance" to you, it is not so for a large and growing number of people.

    May as well ban those pesky Anglo-Roman characters as well just in case I'm using a Cyrillic or Chinese keyboard.

    That 'large and growing' number of people more than likely take a laptop with them. And if you had happened to be a backpacker using public computers for your banking, then you're a freaking moron.

    Your reason for not allowing certain characters remains no reason at all.

  • XOX (unregistered) in reply to Opie
    Opie:
    Exactly. Short and/or limited password fields piss me off to no end, ESPECIALLY on bank sites and other places where personal information is stored. There's no reason for it at all, any more.

    Citibank allows arbitrary-length passwords with spaces and special characters all over the ASCII characted set. I have not tried any unicode values, but I'd be willing to bet they work, if I can enter a passphrase as long as mine is.

    Bank of America, on the other hand, limits you to something like 12 or 20 characters and it can have no spaces or "special" characters, at all, including punctuation and the symbols on the number keys.

    Meh. American Express is worse; they limit passwords to 8 characters, and they don't even warn you that when you set up the account! Instead they just truncate your password to 8 characters. I had a longish password and wondered at first why I couldn't login. I figured it out after a few tries. >.<

  • (cs) in reply to nwbrown
    nwbrown:
    Most keyboards out there are going to have the comma or period or other common 'special' keys somewhere pretty obvious. Otherwise you are going to have a lot more problems with this computer than just entering your password.
    How about the not so common ones? $#|~? If you restrict the special characters to "really common" ones, they don't really make all that much difference.
    Quinnum:
    May as well ban those pesky Anglo-Roman characters as well just in case I'm using a Cyrillic or Chinese keyboard.
    Both of these have the latin letters. If, however, you are Greek or Chinese (or German, Spanish, Swedish...), keyboards in other parts of the world will most definitely NOT have your special letters.
    That 'large and growing' number of people more than likely take a laptop with them. And if you had happened to be a backpacker using public computers for your banking, then you're a freaking moron.

    See posting 144446 above. How about visiting friends or relatives abroad and wanting to check your email account?

    Your reason for not allowing certain characters remains no reason at all.
    You remain to be mistaken.
  • (cs) in reply to KattMan
    KattMan:
    You do not protect from injection by making sure your users never enter injection strings. If you do this, you run the risk of missing something and letting one in.

    This looks like a JavaScript popup, which might mean injection is still possible if, e.g. JS is disabled.

  • bertolli (unregistered) in reply to JOHN
    JOHN:
    B) Banks often require multiple layers of checking as per defined standards. We use methods like this as a backup and as an "early warning system" for detecting people who are potentially up to no good.

    I was thinking along these lines. Some sort of heuristic system can scan (httpd)logs for 'SELECT' statements and such to find potential (naive) hack attempts. A lot of false positives can be prevented by not allowing usernames like that.

  • Jon (unregistered)

    But what if my name really is Mr. '; DROP DATABASE --?

  • (cs) in reply to brazzy
    brazzy:
    See posting 144446 above. How about visiting friends or relatives abroad and wanting to check your email account?
    Then that would be my problem. Why should everybody else be limited in their choices to accommodate a relatively small percentage of users? Let people have enough rope, for god's sake.
  • (cs) in reply to brazzy
    brazzy:
    some dude:
    If you are logging into your bank account from any other keyboard than your own, you have much bigger problems to worry about than a weak password.

    True, but the same problem exists for other applications where that usefulness of having access far outweighs the danger of someone possibly snooping your password. Besides, No online banking application I know will actually let you DO anything with the account after just entering the password. That always requires you to enter a one-time password from a list or something like that. Of course that can be snooped as well, but won't be entered if you just log in to check your balance, and it's useless after the transaction completes, so abusing it requires a rather more complex and targeted infrastructure than a simple key logger.

    Unfortunately every banking application I know gives you full access once you've logged in with a simple username and password, hence being forced to limit myself to an 8 character password of only letters and numbers really pisses me off.

  • Buff (unregistered) in reply to unklegwar
    unklegwar:

    uh...the NUMBERS don't move, and since it's a PIN, you were supposed to pick NUMBERS, which DON'T MOVE (notice that part?). The letters that correspond to the numbers keep changing as a security measure (they transmit the letters, which are different everytime, so an intercepted packet can't ID your pin, someone watching you type can't ID your pin). I CLICK the SAME PATTERN every time. It's the corresponding letter keys which change, which means you can't TYPE the same pattern.

    file under: Clueless

    You're lucky - my Singapore bank account requires a dongle with a magic number, and the little numbers in the popup I have to use to type in my PIN do move around each time :S.. there's secure, and then there's downright annoying.

  • Tom_fan_DK (unregistered) in reply to Jim
    Jim:
    You protect against SQL injection by using parameterized queries NOT by trying to devise some "filter" mechanism to catch hackers.
    The only sensible (and possible) comment, well done!
  • (cs)

    And how in the name of Chuck Norris is this "Security image" supposed to help?

    process:

    1. you insert username.
    2. Bank replies, showing you the image.
    3. you see its right and give your passwords

    If I was a bad phiser, that what Id do.

    1. you insert your user name and post it to me
    2. I post it to the bank site and get your security image
    3. I give you a fake page with the prefetched correct image
    4. you give me your goodies...

    That image must be the most useless security feature ever.

  • Will (unregistered) in reply to death
    death:
    And how in the name of Chuck Norris is this "Security image" supposed to help?

    process: <deleted for breivty>

    That image must be the most useless security feature ever.

    Don't even need to do that. IIRC a recent study showed that close to 95%+ of the participantes in a study on this image system would enter thier passwords even if the image was wrong.

    One of the banks I use has this system and from goofing around with it they do add a little security if the user is watching. In addition to the photo/tag it puts a cookie on the computer and if are using a different computer it asks you some questions you previously answers, standard name of pet, first school,etc.

    As you mentioned and tied in with that recent report the image secuity is worthless. Where it would come in useful is if they just considered the phrase and image as public and then added it to any email they send you. For spammers and phishers it would make it fairly impossible to duplicate that, but as the report showed people don't check the image so it is mostly worthless there also.

    Captcha: Tacos, well I am now off to lunch.

  • John D4xg7b,f4 Smith (unregistered)

    I use my middle name as a password all the time.

  • (cs) in reply to savar
    savar:
    This looks like a JavaScript popup, which might mean injection is still possible if, e.g. JS is disabled.

    It might mean that. It also might mean that this message was created by printing out a picture of a JavaScript popup, placing that image on a wooden table, taking a picture of that image, and mailing it (through snail mail) to the user.

    Lets stick to the facts in evidence when we make fun of these. Its perfectly possible to create a JavaScript popup with sever side checking. And its also perfectly possible to have both client side and server side checking (in fact, that is often considered ideal).

  • Marc (unregistered) in reply to some dude
    some dude:
    If you are logging into your bank account from any other keyboard than your own, you have much bigger problems to worry about than a weak password.

    Uh yeah that was the keyword. They have new login procedures here for homebanking. Check it out: http://www.bcee.lu/bcee/flash/demosnet/en/demo.html (Especially Step 3 is interesting)

    Seems like someone there was thinking :)

  • (cs) in reply to brazzy
    brazzy:
    nwbrown:
    Most keyboards out there are going to have the comma or period or other common 'special' keys somewhere pretty obvious. Otherwise you are going to have a lot more problems with this computer than just entering your password.
    How about the not so common ones? $#|~? If you restrict the special characters to "really common" ones, they don't really make all that much difference.
    Its also wouldn't make much of a difference in terms of security if we banned all O's, 0's, I's, 1's and l's, so lets get rid of them as well to keep the user from getting confused by similar looking characters.

    Allowing common special characters actually gives you about the same increase in security as allowing the user to enter numbers, yet you often find sites that require users to include at least one number in their password. The reason is that by using characters other than alphabetic characters, you force the user to come up with a more unpredictable password. Including things like ,'s and .'s does the same thing.

    See posting 144446 above. How about visiting friends or relatives abroad and wanting to check your email account?
    Then you are shit out of luck. Too bad, you will have to either find out how to enter a # key on your aunt's computer or wait until you get home. Stop trying to protect users against unlikely hypothetical inconveniences at the expense of all your real users.
  • (cs) in reply to Marc

    That demo was good. I liked the step three. theres nothing that key logger would give out and the virtual keypad I bet is scrambled after each load. if all that verification happens in ssl tunnel then the only way I see breaking it is stealing what ever communication happens from memory before https... and I doubt if that can be done at all. And if you can, what protection is used on that data...

  • damn know-it-all kiwi's (unregistered) in reply to Marc

    I would expect that this is in response to concerns about phishing attempts. In otherwords it helps the user to know that they are actually entering their account and password details into their banks website.

  • bg (unregistered) in reply to brazzy

    This is not an issue the people designing the login system should care about. BTW ever heard of Character Map?

  • Hob (unregistered) in reply to bg
    bg:
    This is not an issue the people designing the login system should care about. BTW ever heard of Character Map?
    One could easily look over your shoulder and see what you are trying to copy from Character Map.

    Cheers

  • Nelle (unregistered) in reply to Quinnum
    Quinnum:
    brazzy:
    Pap:
    For the record, I have accounts at ING Direct, E*Trade, and Chase. ING Direct has BY FAR the most secure method of logging in. Both E*Trade and Chase don't even allow ANY special characters in your password.

    Not allowing (or if they are allowed, not using) any special characters is actually a good idea.

    The reason: There are different keyboard layouts for different languages, and while pretty much all of them have A-Z and 0-9, Special characters get shifted around or dropped to make space for the additional characters most languages have. You might end up sitting in front of a keyboard where your special character is not available at all, or only through some weird key combination nobody knows.

    Yeah, reducing security on the off -chance that I'm using a different language computer from my usual one is a great idea.

    I have 5 different layouts installed and have learned from experience not to use special chars (even !%?*) in passwords (letter 'z' can be a problem as well) ...

    And how is security reduced ? You may have limited the password depth, but you can (and should) compensate by increasing its length ..

Leave a comment on “Securing Secure Security”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article