• MF (unregistered) in reply to BEF
    BEF:
    Side note -- it says it's a password for TELEPHONE banking so doesn't it have to be available to the telephone operators? So a one-way hash wouldn't work.

    With the UK banks that I've used, the telephone operators also ask for x, y and z characters of your password which they then enter in a similar system to the internet login shown - i.e., they don't get to see your full password on their screens.

  • Bobbo (unregistered) in reply to lolwtf
    lolwtf:
    My guess is each item has a unit (kg, box, bottle, etc), with "each" being the default. For some reason it's failed to realize that the price per unit isn't valid for "each" and printed it anyway, and that field was NULL, which converts to NaN. Perhaps someone decided to manually type in "each" as a custom unit instead of selecting it from a menu.

    These labels usually say 'per 100g' or 'per litre' to help with price comparison. When it's not an item which can be measured in this way, all the ones I've seen say 'per each' or even 'per ea' in some cases. Yes it's annoying, but you easily forget about it once you've left the shop.

    And yes, the guy who shops at Waitrose has far too much money - Aldi all the way for me!

  • st0815 (unregistered) in reply to JC
    JC:
    Quote: Its called research, it takes but a second, and its the job of an Editor.
    This appears to be a website someone runs on the side for fun...
  • (cs) in reply to NaN
    NaN:
    Yep, that's it.

    Nan == Not a Number exception/error.

    Actually NaN is part of the IEEE floating point spec. Results from any time an operation is performed that is undefined. For instance, division by zero or by +/- infinity.

  • (cs) in reply to lolwtf
    lolwtf:
    Hehe... penetrating the backend.
    operagost:
    The real WTF is "per each". It's simply redundant and wrong. If the issue is a computer system that requires a unit for the item and automatically prefixes "per", then simply use "unit" or "item" for single, nonmeasured items. I guess I'm asking too much out of grocery store workers who hate their jobs.
    My guess is each item has a unit (kg, box, bottle, etc), with "each" being the default. For some reason it's failed to realize that the price per unit isn't valid for "each" and printed it anyway, and that field was NULL, which converts to NaN. Perhaps someone decided to manually type in "each" as a custom unit instead of selecting it from a menu.

    Price per unit is so valid for "each". An eight-pack of candy bars contains eight "each".

    NaN probably came from setting the unit quantity to zero (or maybe null - but it's harder to imagine a SQL NULL being translated to NAN without specific logic to do so) than a rather than one.

  • SCB (unregistered) in reply to Some One
    Some One:
    Matt:
    Did anyone else pick up that asking a user to enter the Nth character of a password guarantees that the bank is storing passwords in cleartext?

    While it suggests they, it doesn't guarantee it....

    They may hash each character (or append something to it and then hash it).

    They might be enciphering using basic encryption (substitution, shift, etc).

    Expensive, but not impossible.

    When you first set up the password, they could store a one-way hash of each combination of the characters that they are likely to ask for. For example: - Hash of first, second, third characters - Hash of first, second, fourth characters - Hash of first, second, fifth characters etc. Then they can hash the three characters that you entered and compare it with whichever stored hash corresponds to the characters that they asked for. Crazy, I know, but possible.
  • James (unregistered) in reply to RobFreundlich
    RobFreundlich:
    From the bank's perspective, that's true. But I'd prefer to not give my password to the people the bank has decided aren't malicious - sysadmins, dba's, random employees who have database access through some WTF, ...

    Yes, if they have database access, they can get to my bank info at that bank without needing my password. But what about all of the other places where I've used that same password, or a variant of it? Yes, I know, I should use a different password for every single site that wants one. But this is the real world, and in the real world there are too many sites, and my wife and I share access to them. So having totally unique passwords per site is not realistic.

    Because of that, every software product I've ever developed has had a strict requirement that passwords should never be stored in plaintext. Ever. In some cases, there were even requirements about how long a plaintext password could be kept in memory.

    So you think that once someone has hacked the bank database and got your password they are then going to use it to post messages on The Daily WTF to make you look stupid ..... oh time to change your password.

  • (cs) in reply to Anonymouse
    Anonymouse:
    iPhone can divide by zero?

    OH SHI-

    U R DOIN IT WRONG. [image] (Disclaimer: The above took me OVER 9000 hours in MS-Paint).

  • (cs) in reply to Matt
    Matt:
    Did anyone else pick up that asking a user to enter the Nth character of a password guarantees that the bank is storing passwords in cleartext?
    It's not inconceivable they've got some clever zero-knowledge proof system. These are banks; they've got proper cryptographers doing proper crypto to protect all that money.
  • (cs) in reply to Otac0n
    Otac0n:
    NaN:
    Yep, that's it.

    Nan == Not a Number exception/error.

    Actually NaN is part of the IEEE floating point spec. Results from any time an operation is performed that is undefined. For instance, division by zero or by +/- infinity.

    Not entirely correct there; both of those operations can produce results other than NaN in at least some cases:
    Special Operations

    Operations on special numbers are well-defined by IEEE. In the simplest case, any operation with a NaN yields a NaN result. Other operations are as follows:

    Operation               Result
n ÷ ±Infinity           0
±Infinity × ±Infinity   ±Infinity
±nonzero ÷ 0            ±Infinity
Infinity + Infinity     Infinity
±0 ÷ ±0                 NaN
Infinity - Infinity     NaN
±Infinity ÷ ±Infinity   NaN
±Infinity × 0           NaN
  • mmj (unregistered) in reply to RobFreundlich
    RobFreundlich:
    Please, please, please tell me that the database has a one-way hash of the password, plus the length in a separate field, rather than the actual plaintext password.

    One-way hash of password != ability to look up individual letters.

    Ergo, they are storing the plaintext.

  • (cs) in reply to AC
    AC:
    If it is anything like the NatWest online banking system (looks the same), it will only ever ask you for a character it knows you'll have.

    Ulster Bank merged with NatWest's predecessor in 1917 - I would suspect that IS the NatWest system.

  • alan (unregistered)

    Same code at RBS in their online banking system. So complex that you have to write down your PIN and password so you can figure out what you need to log on . . . . . resulting in an insecure option. Someone there needs to read some Bruce Schenier books!

  • BAMM (unregistered)

    Great White Buffalo!

Leave a comment on “Sooo Jealous ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article