5 ms·

You underestimate the ingenuity of some sites. Take this one: https://systemschimb.telekombanking.ro/login https://systemschimb.telekombanking.ro/login - enter

You underestimate the ingenuity of some sites. Take this one: https://systemschimb.telekombanking.ro/login https://systemschimb.telekombanking.ro/login - enter a random user id, and behold the password input field: - all characters are separated (not one password field, but 10-15 ones) - some characters are randomly grayed-out (you're not supposed to enter all the characters of your password)

namdnay 6y ago
I like the system where you only enter parts of your password. It means that even with a key logger or hacked site, you’d need several logins to be able to scrape the password
- iso1631 6y ago
  That means the password is held in plain text or reversable encryption. They should only have a salted hash of your password. Using a shared secret in addition to a salted password is probably acceptable, although how much extra security it gives is debatable.
  - ithkuil 6y ago
    Possibly or they could store N salted hashes, one for one of the N permutations of a mask over the password character positions. This basically splits the end user password into N passwords with smaller entropy but this can be mitigated by requiring high entropy for the original password.
    - iso1631 6y ago
      Making it insanely easy to brute force if you have access to the hashes (if they ask for 2 characters, assuming a-zA-Z0-9 you're talking maybe 4k permetations, and then you know 2 characters) A 10 character 64 symbol phrase would take 64^10, or 1e18 guesses 5 lots of 2 characters 64 symbols would take 5*64^2, or 20k guesses
      - ithkuil 6y ago
        If the "sub" passwords are 2 char long then then they have way too less entropy. For this to that make any sense it must use a sizable subset of the full password (which must be longer than usual to accommodate for that. And all this to protect for keyloggers. Probably a hardware token second factor is more effective.
- ArgyleSound 6y ago
  Yet it also suggests the password is being stored insecurely in the server.
megapatch 6y ago
It is missfeatures like this which make me seriously doubt the competence of the site provider. They then loose me as a customer, and everybody else who I can influence.
- user5994461 6y ago
  Looks like a bank. It was (is?) common practice to have a visual keyboard to enter the password in extremely sensitive applications like banking. This prevents the password from being captured by keyloggers and from being saved by the browser, because malware automatically extract and collect these, which was a very real issue with banking.
nobatron 6y ago
This approach also means that the password must be stored as plain text. Otherwise they would only be able to compare if the password was complete.
- mormegil 6y ago
  Not necessarily. You could store $10 \choose 5 = 252$ hashes for each user. We did something similar for call center caller authentication (you don't want the operator to get the whole PIN of the user, so he asked only for e.g. two characters). Not that this would be very useful, security-wise.
  - viraptor 6y ago
    There are ready solutions for that too. For example https://github.com/bizley/yii2-partial-password https://github.com/bizley/yii2-partial-password
  - dmurray 6y ago
    > Not necessarily. You could store $10 \choose 5 = 252$ hashes for each user. Wouldn't this be way easier to crack if the password hashes were leaked? Once you crack one 5-letter hash, you can trivially crack the one that shares 4 characters with it, and do that repeatedly until you have all 10 characters. You're reducing the effective search space not by a factor of 252 (8 bits of entropy, which would often be acceptable) but to its square root, losing half of the entropy. Although it seems like security theatre, the PIN solution actually sounds more useful. The typical attack on a system protected by PINs, like bank cards, is not cracking hashes offline - it's that the attacker tries the PINs on the live system and gets locked out after a small number of failures. Assuming the bad actor can't just initiate another call and ask for the other two digits.
    - mormegil 6y ago
      Oh, sure, the authentication itself is fairly usable for the given usecase, the hashing is security theater. I advocated not hashing those PINs, but you know, standards, auditors, etc. "Passwords must be hashed", security theater or not.
phit_ 6y ago
the page uses vue and its in development mode, just wow https://i.imgur.com/87Z46vb.png https://i.imgur.com/87Z46vb.png
dkersten 6y ago
Wow. Even if I didn’t use a password manager, that last point would make this unusable for me. When I do use passwords, I remember them through muscle menory, and having to not type parts of it would throw me off. I would actually change banks over that.

namdnay 6y ago

I like the system where you only enter parts of your password. It means that even with a key logger or hacked site, you’d need several logins to be able to scrape the password

iso1631 6y ago
That means the password is held in plain text or reversable encryption. They should only have a salted hash of your password. Using a shared secret in addition to a salted password is probably acceptable, although how much extra security it gives is debatable.
- ithkuil 6y ago
  Possibly or they could store N salted hashes, one for one of the N permutations of a mask over the password character positions. This basically splits the end user password into N passwords with smaller entropy but this can be mitigated by requiring high entropy for the original password.
  - iso1631 6y ago
    Making it insanely easy to brute force if you have access to the hashes (if they ask for 2 characters, assuming a-zA-Z0-9 you're talking maybe 4k permetations, and then you know 2 characters) A 10 character 64 symbol phrase would take 64^10, or 1e18 guesses 5 lots of 2 characters 64 symbols would take 5*64^2, or 20k guesses
    - ithkuil 6y ago
      If the "sub" passwords are 2 char long then then they have way too less entropy. For this to that make any sense it must use a sizable subset of the full password (which must be longer than usual to accommodate for that. And all this to protect for keyloggers. Probably a hardware token second factor is more effective.
ArgyleSound 6y ago
Yet it also suggests the password is being stored insecurely in the server.

megapatch 6y ago

It is missfeatures like this which make me seriously doubt the competence of the site provider. They then loose me as a customer, and everybody else who I can influence.

user5994461 6y ago
Looks like a bank. It was (is?) common practice to have a visual keyboard to enter the password in extremely sensitive applications like banking. This prevents the password from being captured by keyloggers and from being saved by the browser, because malware automatically extract and collect these, which was a very real issue with banking.

nobatron 6y ago

This approach also means that the password must be stored as plain text. Otherwise they would only be able to compare if the password was complete.

mormegil 6y ago
Not necessarily. You could store $10 \choose 5 = 252$ hashes for each user. We did something similar for call center caller authentication (you don't want the operator to get the whole PIN of the user, so he asked only for e.g. two characters). Not that this would be very useful, security-wise.
- viraptor 6y ago
  There are ready solutions for that too. For example https://github.com/bizley/yii2-partial-password https://github.com/bizley/yii2-partial-password
- dmurray 6y ago
  > Not necessarily. You could store $10 \choose 5 = 252$ hashes for each user. Wouldn't this be way easier to crack if the password hashes were leaked? Once you crack one 5-letter hash, you can trivially crack the one that shares 4 characters with it, and do that repeatedly until you have all 10 characters. You're reducing the effective search space not by a factor of 252 (8 bits of entropy, which would often be acceptable) but to its square root, losing half of the entropy. Although it seems like security theatre, the PIN solution actually sounds more useful. The typical attack on a system protected by PINs, like bank cards, is not cracking hashes offline - it's that the attacker tries the PINs on the live system and gets locked out after a small number of failures. Assuming the bad actor can't just initiate another call and ask for the other two digits.
  - mormegil 6y ago
    Oh, sure, the authentication itself is fairly usable for the given usecase, the hashing is security theater. I advocated not hashing those PINs, but you know, standards, auditors, etc. "Passwords must be hashed", security theater or not.

phit_ 6y ago

the page uses vue and its in development mode, just wow https://i.imgur.com/87Z46vb.png https://i.imgur.com/87Z46vb.png

dkersten 6y ago

Wow. Even if I didn’t use a password manager, that last point would make this unusable for me. When I do use passwords, I remember them through muscle menory, and having to not type parts of it would throw me off. I would actually change banks over that.