4 ms·
It's a ridiculous practice and storing the passwords in plaintext is deplorable. Banks have your phone number, (which can't simply be changed online) and that i
by pierrec 10y ago
It's a ridiculous practice and storing the passwords in plaintext is deplorable. Banks have your phone number, (which can't simply be changed online) and that is the best additional line of security.
The scrambled on-screen keyboard / n-th character request only poorly "protects" against cases where the attacker has full root access to the customer's machine (how would it protect against phishing?), and in those cases the attacker is likely already capable of making all kinds of payments, even without access to the online banking account. If security is done properly, an attacker can't make direct use of a banking account anyways: creating a new transfer recipient should require phone confirmation by default.
- GhotiFish 10y agoyou know. It occurs to me that you could actually do this without storing the password in plaintext! All you'd have to do is iterate every potential answer into a bloom filter and store that. The math gets a little hairy around the 50 character mark as you'd have 117600 operations to do to construct the bloom filter, and it gets worse if you expect more characters. Here's how you would construct it. For every 3 choose n of the password, insert a value of those 3 characters ("abc") + delimit (":") + the positions (1,2,4), You can't just insert the characters because the index of characters is part of the answer. all you'd need to do is store... a ~1MB bloom filter per client. Huh, that number was bigger than I thought it would be. Well nevermind. Fun thought though.
- Vexs 10y agoRealistically you could also just limit it to the first 10 characters.