I don't use Usenet much these days (so forgive me if I am not prompt to reply) but I've just come across a sci.crypt adjacent question.
My bank offered to allow me to log in today using my "memorable data"
(MD) rather than my password. This MD is just a string you can choose
and it is essentially arbitrary. They hope you will make it longer than
a password but easy to remember.
So far so good. I thought (when I signed up years ago) that this MD
would be used as an extra, in person, check over the phone. But the
login page prompts for four selected characters from it, for example the
2nd, 5th, 6th and 12th. How does the server check these without storing
the MD in plain text?
We all know that servers don't (at least shouldn't) store passwords.
They store hashed data and hash what you type to do the comparison. But
with only selected characters being asked for what do they do? Is there
some clever maths that has passed me by, or is there something not very secure going on here?
On 05/08/2026 17:21, Ben Bacarisse wrote:
So far so good. I thought (when I signed up years ago) that this MD
would be used as an extra, in person, check over the phone. But the
login page prompts for four selected characters from it, for example the 2nd, 5th, 6th and 12th. How does the server check these without storing the MD in plain text?
I suppose they could hash, 'A----', '-B---', '--C--' etc. I bet they
don't hash it at all.
My bank is now allowing (or rather: forcing) me to login with just my username and memorable data. They used to want username+password+MD.
They say not needing the password makes it easier and no less secure.
For your reference, records indicate that
Richard Harnden <richard.nospam@gmail.invalid> wrote:
On 05/08/2026 17:21, Ben Bacarisse wrote:
So far so good. I thought (when I signed up years ago) that this MD
would be used as an extra, in person, check over the phone. But the
login page prompts for four selected characters from it, for example the >>> 2nd, 5th, 6th and 12th. How does the server check these without storing >>> the MD in plain text?
I suppose they could hash, 'A----', '-B---', '--C--' etc. I bet they
don't hash it at all.
Given that itrCOs a bank, I would *hope* theyrCOre doing better than that. They might be doing some sort of shared secret scheme. The rabbit hole to
go down is:
<https://en.wikipedia.org/wiki/Partial_password>
Regardless, it sounds like a really dumb way to implement a password replacement. I mean, why bother supporting a human-friendly pass phrase
like `correct horse battery staple` if yourCOre just going to immediately turn around and make them start doing arbitrary index calculations on it? Times four!
My bank is now allowing (or rather: forcing) me to login with just my
username and memorable data. They used to want username+password+MD.
They say not needing the password makes it easier and no less secure.
It certainly can/should be. Given a long enough phrase, you donrCOt even need a username, but it does serve as a handy unique rCLsaltrCY for the hash. To my thinking, supporting a username is kind of dangerous, because that
then encourages sharing the same secret on multiple sites, which is one
of the things that makes hard passwords problematic. The hash (and/or a derived token) is the *actual* key underneath, so why pretend otherwise?
IrCOm doing this right now for a project IrCOm working on. The idea being that I want to invert the value of short/common account names (i.e., if
you use just `rick` to set it up, itrCOs not going to be very secure, but yourCOd probably be OK with `rick is a super cool guy with a dog named dumdum`).
Given that it's a bank, do they know how to generate these phrases
securely? This is not an idle question, as people have been draining "cryptowallets" for this very reason.
A large part of the problem with bank security, is that the people we
talk to -- generally the tellers -- have no authority to question the security, if we the customers point out that something isn't as safe as
the bank claims it is.
For your reference, records indicate that
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
Given that it's a bank, do they know how to generate these phrases
securely? This is not an idle question, as people have been draining
"cryptowallets" for this very reason.
Tech bros are (very intentionally) not banks. Actual banks are going to
be on the hook for losses, not running rug pull frauds from the inside.
Which is not to say any individual bank employees is above trying it, or
that rCLtoo big to failrCY bailout nonsense doesnrCOt happen, of course.
A large part of the problem with bank security, is that the people we
talk to -- generally the tellers -- have no authority to question the
security, if we the customers point out that something isn't as safe as
the bank claims it is.
IrCOve worked for banks before, and thatrCOs simply not true. As a regulated industry, there are *many* mechanisms in place for customers and employees
to report problems they see, including doing so anonymously. Please name
an actual bank and describe their behavior that has you making such a
claim. Mere speculation on hashing algorithms isnrCOt enough.
IrCOm doing this right now for a project IrCOm working on. The idea being that I want to invert the value of short/common account names (i.e., if
you use just `rick` to set it up, itrCOs not going to be very secure, but yourCOd probably be OK with `rick is a super cool guy with a dog named dumdum`).
I don't use Usenet much these days (so forgive me if I am not prompt to reply) but I've just come across a sci.crypt adjacent question.
My bank offered to allow me to log in today using my "memorable data"
(MD) rather than my password. This MD is just a string you can choose
and it is essentially arbitrary. They hope you will make it longer than
a password but easy to remember.
So far so good. I thought (when I signed up years ago) that this MD
would be used as an extra, in person, check over the phone. But the
login page prompts for four selected characters from it, for example the
2nd, 5th, 6th and 12th. How does the server check these without storing
the MD in plain text?
Oh, I was thinking of my attempt to show my local branch manager that
using SMS for two factor authentication wasn't as secure as the official spiel from the bank made it sound like.
What 2FA does your bank use? Do you believe I stood a chance, as a mere customer, to get the bank to use something else for the two factor?
I really have no idea what you expect any suggested change to
accomplish.
Banks are likely doing more risk assessment on the alternative
schemes than we have or the branch manager is able to do.
IrCOve never had *any* form of MFA be anything more than a hassle,
because IrCOve never had anyone get to/past the password challenge.
On 06/08/2026 2:25 AM, Doc O'Leary wrote:
IrCOm doing this right now for a project IrCOm working on. The idea being that I want to invert the value of short/common account names (i.e., if
you use just `rick` to set it up, itrCOs not going to be very secure, but yourCOd probably be OK with `rick is a super cool guy with a dog named dumdum`).
How are you generating your code words?
Happy non-random biased code word selection!
For your reference, records indicate that
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
Oh, I was thinking of my attempt to show my local branch manager that
using SMS for two factor authentication wasn't as secure as the official
spiel from the bank made it sound like.
Well, IrCOd generally say there can be a vast gulf between rCLas secure asrCY and rCLinsecurerCY. In a retail setting, absolutely *nothing* is top-shelf security, because no regular customers would use it.
What 2FA does your bank use? Do you believe I stood a chance, as a mere
customer, to get the bank to use something else for the two factor?
I really have no idea what you expect any suggested change to accomplish. Banks are likely doing more risk assessment on the alternative schemes than we have or the branch manager is able to do. IrCOve never had *any* form of MFA be anything more than a hassle, because IrCOve never had anyone get to/past the password challenge.
Ben Bacarisse <ben@bsb.me.uk> wrote:
I don't use Usenet much these days (so forgive me if I am not prompt to
reply) but I've just come across a sci.crypt adjacent question.
My bank offered to allow me to log in today using my "memorable data"
(MD) rather than my password. This MD is just a string you can choose
and it is essentially arbitrary. They hope you will make it longer than
a password but easy to remember.
So far so good. I thought (when I signed up years ago) that this MD
would be used as an extra, in person, check over the phone. But the
login page prompts for four selected characters from it, for example the
2nd, 5th, 6th and 12th. How does the server check these without storing
the MD in plain text?
They /could/ be doing what Richard suggests, but I agree with Richard's final conclusion, they likely are not hashing anything and likely
storing the "memorable data" as plain text.
On the other hand, there /is/ one way they could be 'hashing' it, and
if so that means this becomes very very insecure.
You given them "correct horse battery staple" [1] as your memorable data.
They "randomly" [2] select indexes 3, 6, 12 and 17 (ones based, as most normal humans don't label the "first" character as character zero).
That gives r c s t (if my index counts have been correct) from this memorable data.
They combine these four into "rcst" and hash and store that hash.
And... every time you log in, they always ask for indexes 3, 6, 12 and
17 from your "memorable data".
Which means, /if/ this is what they have done, then they now have
everyone using a "four character" password due to their own
incompetence. Not good.
But I could see some "bank type" thinking this was an "unbreakable
password" system much like our old crank with his Ada code systems used
to think every one of his schemes was uncrackable.
So, let us know if they ask for different index positions with each new login, or if they always ask for the same set of indexes?
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 52:22:52 |
| Calls: | 1,101 |
| Calls today: | 1 |
| Files: | 1,339 |
| Messages: | 276,091 |