Creating Unique, On-Demand IDs for Website Customers

[Skeetre]

Ok...have a question that probably belongs somewhere else, but due to my "low output" as a member, I am posting here in the hopes that someone can redirect me and/or my post. So, thanks in advance.

Also, the situation I describe below is not about my work as a tech; rather, it's about my recent encounter with what I consider to be a serious security flaw and auditing process by my credit union. So I am coming at this from the perspectives of both a tech and a member of the credit union.

Here goes....

The credit union sent out last week an e-mail (to me; some members got actual letters while some got e-mails) regarding an upcoming election of their Board of Directors. The e-mail was, I believe, a near-textbook example of a phishing e-mail: it did NOT originate from the credit union; it referenced and claimed to be sent on behalf of the credit union; it provided a link to a third-party site which requested parts of member information; there was no prior e-mail-based announcement regarding such an e-mail being sent to members on behalf of said credit union.

My concern, obviously, was that an attempt was being made to collect some member information from me, as well as other credit union members. And that the credit union was not aware of this and needed to be made aware.

So, I set out to do just that, culminating (at least, so far) today with a 45-minutes-long conversation with the credit union's "Chief Audit Executive."

Prior to today's conversation with Mr. CAE, I had sent via e-mail a list with 13 questions/concerns about not only the "phishing e-mail," which Mr. CAE claimed was actually an approved and legitimate e-mail, but about the linked-to site from that e-mail. (The site was given a "F" at SSL Labs.)

Mr. CAE and I went over the bulk of that list. And the outcome, yet to be experienced, will be a separate issue.

However, during our discussion, Mr. CAE indicated to me that the CU had thought long and hard about how to provide relatively easy access to voting in the election WITHOUT compromising member information (and admirable goal, of course). This e-mail, something Mr. CAE acknowledged to me in our conversation looked like a phishing e-mail, was the result of the CUs many discussions.

I suggested that there must be some way to create a unique ID for each voting member that would keep the member's account/personal information private. (In this case the CU provided the third-party site with the last three of the member's zip code, last four of their SSN and their full date of birth. I objected to all of these, even though the first two items were not, in and of themselves, really enough to (probably) be troublesome. The third-party site also had members' names and e-mail addresses, something to which I did object.

So again, what I thought could be done was to provide each voting CU member a unique, one-time-use ID that would be passed along to the third-party site WITHOUT having to divulge ANY of the members' personal information.

This, then, is the question: is this possible?

My thought (I'm not a programmer and know nothing of website construction or the like) would be to provide a link ON THE CREDIT UNION SITE that is available to a member AFTER LOGIN. This, presumably, would: 1) keep the members' information local (such as it is); 2) ensure that the ID is being issued to the real member ON A TRUSTED SITE; 3) be passed on to the appropriate third-party site WITHOUT THE PASSING ALONG OF MEMBER INFORMATION; 4) perhaps have even other benefits of which I'm not aware.

Anyway, I would like to be able to come back to Mr. CAE with a viable solution that benefits both the CU and us members.

So again, what I'm wondering is: is it possible to create a one-time-use only, unique ID for a website's users? I'm sure it is, but I think I need a programmer or someone like that to help me (help myself).

Sorry for the very long (and inappropriately placed) post. But it would be awesome if some kind soul(s) would point me in the right direction.

Also, if I need to clarify something or whatever, don't hesitate to let me know.

Thanks so much!

 

[Bryce W]

Yep, its doable.
You see a similar system when you initiate a password reset on most sites. You get a unique ID (eg. site.com/lostpassword.php?id=450dfgh3702fh534sdfng) that gives you special access (the password change area of that account) for an amount of time.

The unique ID could be made up with a formula that only they know so they can reverse it.

 

[Skeetre]

I agree, Bryce W. I'm just not sure why the CU did not opt for what appears to me to be a relatively easy method of doing so, which also happens to allow for NO personal/account information being handed over to a third party.

Overthinking? Not creative enough? Didn't discuss this with the right people?

Terribly confusing, from my perspective.

Anyway, thanks for the information.

 

[Your PCMD]

You get a unique ID (eg. site.com/lostpassword.php?id=450dfgh3702fh534sdfng) that gives you special access (the password change area of that account) for an amount of time.

Thats different than from what the OP is suggesting. In the php/SSH world, that number given is also the same number for the session ID. In the DB that number is stored temp as an encrypted SSH/SSH2 number, so when you use the link, that number - 450dfgh3702fh534sdfng - must match the encrypted number in the DB for it to work.

You can however truncate the number at the same time and store in the DB of the CU member. BUT, as far as I know, every member of a CU or any bank for that matter already has a unique ID number other than their bank account number.

The very first path of any user in a database is always the ID number. So why not use that? The company doing the service for the CU could simply ask for the ID number (of which the CU would provide to the customer - in a letter of some sort). The customer could simply enter that number on the companies form and submit their vote. Company would give the data in such a way of ID number yes and no column then the CU can see how many voted yes or no. There are of course other ways to do it.

 

[Skeetre]

Thats different than from what the OP is suggesting. In the php/SSH world, that number given is also the same number for the session ID. In the DB that number is stored temp as an encrypted SSH/SSH2 number, so when you use the link, that number - 450dfgh3702fh534sdfng - must match the encrypted number in the DB for it to work.

You can however truncate the number at the same time and store in the DB of the CU member. BUT, as far as I know, every member of a CU or any bank for that matter already has a unique ID number other than their bank account number.

The very first path of any user in a database is always the ID number. So why not use that? The company doing the service for the CU could simply ask for the ID number (of which the CU would provide to the customer - in a letter of some sort). The customer could simply enter that number on the companies form and submit their vote. Company would give the data in such a way of ID number yes and no column then the CU can see how many voted yes or no. There are of course other ways to do it.

Interesting.

I would suggest that, at least from my perspective of limited knowledge, that "unique ID number" might be information that the CU, in an effort to minimize the dissemination of member data, would be reluctant to give. Maybe; maybe not. As a member, however, I do not want any personal/account information passed around. So I rather like creating a one-off and unique character set for each member upon log-in.

Still, it's puzzling to me why the CU did it the way they did, what with all of the fraud- and security-related people and groups they must have.

 

[Your PCMD]

Still, it's puzzling to me why the CU did it the way they did, what with all of the fraud- and security-related people and groups they must have.

Exactly.

 

[Skeetre]

Ok...so I e-mailed my contact at the CU and suggested something. (NOTE: I'm not any sort of guru when it comes to cryptography, obviously.)

I suggested that they take some random data (today's date, various words/characters/numbers plus whatever) and then apply a hashing function to it (comprised of some/all of member data (presumably account number), producing a character set that cannot be reverse engineered and that does not identify members to outside organization.

(Does that even make sense?)

Anyway, we'll see.

 

[Your PCMD]

I suggested that they take some random data (today's date, various words/characters/numbers plus whatever) and then apply a hashing function to it (comprised of some/all of member data (presumably account number), producing a character set that cannot be reverse engineered and that does not identify members to outside organization.

That is just too much trouble for an easy solution.

Most financial institutions only require the last 4 numbers of an account to identify you. Therefore, just use a simply SHA1 key.

Example: 1234 in SHA1 would be 7110eda4d09e062aa5e4a390b0a572ac0d2c0220

Note that SHA1 will always create a 40 character key, even if you use just 1 number/letter or 100.

It would be easy for the CU's IT dept that oversees their database to write a small php/sql script to convert each members last 4 account number into an SHA1 and insert a new key into each members TABLE to create a new COLUMN using ALTER TABLE then after it was over, use ALTER TABLE along with DROP COLUMN.

The whole script can be written inside 3 pages of php code. One to create it, one to read the results from the poll (which is essentially what the company gathering the info for uses) and the last to read the results and remove the temporary added COLUMN for each member.

This is essentially how most polling scripts work, except they use your IP address with a session id. How do you think your only able to vote once? The poll feature on this very forum is the same thing.

 

[Skeetre]

That is just too much trouble for an easy solution.

Most financial institutions only require the last 4 numbers of an account to identify you. Therefore, just use a simply SHA1 key.

Example: 1234 in SHA1 would be 7110eda4d09e062aa5e4a390b0a572ac0d2c0220

Note that SHA1 will always create a 40 character key, even if you use just 1 number/letter or 100.

It would be easy for the CU's IT dept that oversees their database to write a small php/sql script to convert each members last 4 account number into an SHA1 and insert a new key into each members TABLE to create a new COLUMN using ALTER TABLE then after it was over, use ALTER TABLE along with DROP COLUMN.

The whole script can be written inside 3 pages of php code. One to create it, one to read the results from the poll (which is essentially what the company gathering the info for uses) and the last to read the results and remove the temporary added COLUMN for each member.

This is essentially how most polling scripts work, except they use your IP address with a session id. How do you think your only able to vote once? The poll feature on this very forum is the same thing.

Thank you for the education...seriously. I don't code, and so learning something about this is helpful.

It appears that there are easy-to-implement methods that: 1) provide the verification required by the CU; 2) ensure the anonymity members deserve; 3) meet the one-vote-per-member requirement.

So, why on God's green earth did they not do it this way? Makes no sense to me.

 

[Your PCMD]

So, why on God's green earth did they not do it this way? Makes no sense to me.

I totally agree!

 

[Markverhyden]

Why not two factor authentication? It should be part of their login in anyways.

 

[glennd]

a variation on Bryce's general concept would work if they wanted to keep it in house (ie use their own servers). if they really wanted to outsource the job, @Your PCMD 's SHA1 idea would be the thing to do. You give them a list consisting of an email and a SHA1 which is generated from customer information and is not reversible. They do the poll and send back a list of SHA1 and yes/no response. However this still leaves the problem of giving away the customer mailing list which could be considered a breach of privacy. And there is really no excuse at all for giving out any more than that.

The thing with the SHA1 (I think, someone correct me) is if you use the same formula and same source information, you will get the same number so you don't even need to store the number. When the script is storing the results returned from the outsource, it can simply regenerate the number from the customer database in order to find the match. This assumes the source information doesn't change and the customer ID will never change; it is absolutely unique to the customer and can not change for the life of the database in question. Modern relational databases are very efficient (if designed properly) so if you store this SHA1 number and never use it again, it's no big deal. And rule number two is you never delete information.

caveat: i'm not much of a php coder so i can't be specific.

So, why on God's green earth did they not do it this way? Makes no sense to me.

Done in ignorance. The suits would not be expected to have this level of insight into how to do this kind of thing but their I.T. people should have known better. Failing that they should have consulted someone with a modicum of knowledge about this stuff.

 

[Skeetre]

As I think more about this entire situation, I'm both frustrated and amused: frustrated by the astounding lack of security- and privacy-mindedness and amused by how the "Chief Audit Executive" really tried to work me over in explaining the process.

I even asked Mr. CAE what exactly it is he does as "Chief Audit Executive." He took offense at that, declining to answer.

It really is amazing, and pathetic, that in an age of almost countless security breaches, any financial institution would be so incompetent/irresponsible/unprofessional in such things, especially given how patently easy it is to do it correctly.

Oh, and by the way, Mr. CAE also shared with me that members' financial statements are NOT done in-house, something about which I had no clue. Boggles the mind (well, at least mine).

Thanks for all the comments and suggestions. I will update when I hear from Mr. CAE.