posted
Last time I posted an encryption problem here, Papa solved it almost instantly. I suspect this one is a whole different kettle of fish, but since the combined brain power here fairly seethes, I thought I'd give it a try.
I have a vendor. The vendor has two different databases for two different applications. The vender would like us to be able to tie the two together in some reports. For this purpose, they include an identifying number from database A in all records in database B. They do it freeform, so there can be typing errors (<kill me now>).
This would be simple, except that application B stores the number from database A in encrypted form.
For example, a record with the identifier 940973277 ties (based on the name, at least) with a couple of dozen records in the other database. But the encrypted info for that person (I think) has five different values. One is NULL, which just means that whoever entered it didn't bother with the number. The other four are these:
I can see that only the first 8 characters differ from one to the other. So maybe the final 20 characters are the ones that match 940973277. Or maybe not. I can also see that all of them have the substring zwL2 in them. Which might mean that this is a delimiter, and that the encrypted part is actually only vjz3lCvzlQHi.
Any thoughts, O Wise Ones?
Posts: 12266 | Registered: Jul 2005
| IP: Logged |
posted
. . . methinks there's a strange obsession with encryption that isn't encryption . . .
Sorry I'm not more helpful, but it all depends on how they're hashing them. If they have even a semi-okay hashing algorithm, you can't compare like that. Based on the previous question . . . you might get lucky.
Wait, in order for them to compare the 'encrypted' form you'd have to know the encryption function, even absent typing errors, wouldn't you?
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
They would. Application A stores the number and retrieves it, but we don't have the source code for Application A. Our customer (I meant customer, not vender, above) has asked the people who make the software to help, but they can't be bothered.
Posts: 12266 | Registered: Jul 2005
| IP: Logged |
posted
Ouch, sorry you have to deal with even more of this stuff. Especially when they're not getting any value out of their encryption besides feeling good about adhering to best practices (not) and making your work painful.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
The bad part is that they only hired us because my boss promised them we could consolidate the data in reports. And I have an unfortunate track record at this company of pulling rabbits out. It makes them unwilling to listen when I say something is probably impossible.
Posts: 12266 | Registered: Jul 2005
| IP: Logged |
posted
If I'm understanding right, you see the zwL2 pattern twice in every record in the database that isn't null?
Can you see if there are any sharing the vjz3lCvzlQHi substring (in the right place) that aren't for this record? If there are, is the id really close to 940973277?
If there are relatively few people in the database (preferably a few thousand, maybe under a million), I'd run that test on every pair of records with matching names (treating separately pairs of records where there's a name that's known to be a duplicate in one or both of the databases), and see the results.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
It looks sort of like a base 64 hash, based on my limited ken (includes both uppercase and lowercase A-Z characters as well as numeric characters). However this decoder doesn't seem to do anything intelligible. So there's evidently something more (or less) to it.
Posts: 4287 | Registered: Mar 2005
| IP: Logged |
posted
Using this decoder doesn't come up with legible either.
Then again, taking their past history of encryption, I'm not expecting something worthy of Department of Defense work...
Posts: 3486 | Registered: Sep 2002
| IP: Logged |
posted
If it's a standard hash then you might be able to use this site to try and find out what it is. I tried hashing the record id though but didn't have any luck.
EDIT: If you can figure out what hash function is used then you could probably find some database of "common" hash values and, if you're lucky, reverse engineer it.
Posts: 1327 | Registered: Aug 2007
| IP: Logged |
posted
Yeah, the previous 'hash' pretty conclusively showed the people writing these applications had no idea what they were doing in that regard.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
It was a different app, though. I went in and pulled all records with non-null, non-blank IDs, and got just short of 17K records. Almost every single one ended with zwL2, and the vast majority had a zwL2 in places 9-12 as well.
I give up. I just looked at the following records:
(I put the separations in, because I was looking for patterns.)
Note that the first and last record are two different hashes, and that all of the middle ones are a third hash. So I looked through the many fields in this table, and found that there isn't a single thing that's common to all of those middle records, but different for the first and last one. This is a waste of time. Sorry for wasting yours.
Posts: 12266 | Registered: Jul 2005
| IP: Logged |
Printer-friendly view of this topic
