• (nodebb)

    If you hex-encode and then base64-encode it a total of 3 times, then the payment endpoint becomes extremely secure.

  • (nodebb)

    I read the title as "Bash of the Hash." Equally appropriate, I think.

  • Jaloopa (unregistered)

    486F77206D616E792070726F626C656D7320617265206361757365642062792070656F706C65206E6F742072656164696E672074686520646F63733F

  • AzureDiamond (unregistered) in reply to Mr. TA

    You can never guess my password then. NGU0NzUxMzI1YTQ0NTEzMjRlNmE2YjMwNWE2YTU1MzA0ZTU0NmIzMzU5NTQ1MjZkNGU1NDUxMzA0ZDZhNWE2ODRlNDc1NTdhNGQ2YTU1Nzk0ZTZhNmIzMTU5NTQ1NTMwNGU0NzUxN2E0ZDQ0NTI2YjRlMzI0NTMyNTk3YTVhNjk0ZTU3NDUzMTRlNDQ1OTdhNGQ3YTQxMzE1OTU0NTEzMDRlNDQ0OTMyNTk1NDUyNmQ0ZTU0NjMzMDRmNTQ2MzMzNGU1NDZiMzI1OTU0NTEzMTRkN2E0ZDMwNWE1NDVhNjg0ZTZhNGQ3YTVhNDEzZDNk

  • Hanzito (unregistered)

    I've seen the same: hmac signing using the hexadecimal representation of the key. While it's not terrible, it did make me go through the same steps, with the bonus complication that the support staff had no technical knowledge whatsoever. Later, in a call over another issue, they called in one of the devs, and he said that we were the only ones that actually had the signing working. I kept my mouth shut.

  • (nodebb)

    Maybe they're consuming too much hash. Time for a random drug test?

  • Argle (unregistered)

    "I’m not prepared to continue my line of inquiry any further. I think this is getting too silly."

    "Quite agree. Quite agree. Silly, silly, silly. Right! Get on with it…. Get ON with it!"

  • Duke of New York (unregistered)

    I once worked on a library with implementations for both iOS and Android that sent a hash of the device MAC address to a peer server library. Never mind why. Above a certain release, both iOS and Android will read a bogus placeholder MAC address, so the server library had to recognize the hash of that value and ignore it.

    As it happened, the iOS and Android libraries, each developed in the same small startup company, quite possibly by the same person, calculated the hash differently. One hashed over the bytes, the other over the hexadecimal digits. This had been signed off in code reviews and QA long before I showed up, so the server library had to check for both.

  • Randal L. Schwartz (github)

    Reminds me in a way of the problems with emojibake when encoding meta-information is missing or incorrect.

  • Jor (unregistered)

    I've had a similar experience where after cursing for hours I found they needed the MD5 hash of a value, in ASCII hex, encrypted using AES and an ASCII hex key. I suspect they implemented it all in PHP (which is of course not that consistent with functions that return a hex representation vs the actual data), then when implementing it for the first time in a client decided to just leave it be.

  • Your Name (unregistered)

    Don't you love hashes. Fun with SEPAXML files, when you put them in "containers" you need to calculate a hash over it, which is also stored in the XML. For extra stupidity the hash is put in front of the data to be hashed. Which is really nifty when you create a container file. Write the contents out, adding up the hash, then go back and "insert" the hash value.

    The hash method is quite well defined, but it just wouldn't match up with the required value the banks wanted. Through trial and error I found out that the hash needs to have attributes in the root tag, which the end file must not have.

    Plus that one bank, that wouldn't use the encoding of the XML file and got wrong hash values when Umlauts (e.g. ä, ö, ü) were inside.

  • Jan (unregistered) in reply to AzureDiamond

    It's hunter2. You need more hex/base64 passes, 3 is not secure enough

  • (nodebb)

    Why do so many developers, especially with these weakly-typed scripting languages, think everything needs to be a string? Is no-one teaching these people about how data gets represented in computer memory? I've had junior developers ask me how to get an integer converted to binary so they could do things like bit-masking. We're talking about e.g. 32-bit unsigned integer variables. I have to keep calmly explain that they are already in binary.

  • Gonzo (unregistered) in reply to prueg

    I have to keep calmly explain that they are already in binary

    Welcome to the world of software development past 2015 :)

  • Plant (unregistered)

    I'm pretty sure somebody just mind blanked and thought base64 encoding and a hexadecimal string are the same thing.

  • Wayne (unregistered)

    I learned a long time ago that just because a payment provider is a bank, it doesn't mean that their IT people are the brightest bulbs. One job I was doing for a city gov't involved setting up an SFTP job that contacted their box, downloaded utility payments, then reformatted them for our database to ingest them. I standardized the process so the only thing that had to be changed for new providers were the SFTP connection info and a couple of lines of code that identified whom the incoming file was from. I think we had four payment providers and everything worked great, except for one bank. For some reason, their file came in as one huge unbroken line of code, instead of one record per line. No CR/LF. I call their alleged programmers and am discussing the problem and the person on the other end did not understand that the CR/LF took up space in the file.

    Turned out there was something about the SFTP program that I was using that was interacting weird with their servers that might have been causing the CR/LFs to be stripped? This person was clueless in trying to resolve it, so I had to reconfigure all of the file transfer for all of the other vendors to work with a different SFTP program, repeating all of the testing. Too much fun.

    I have other bank stories equally stupid, which is why I won't open an account with my local bank, perhaps to share another time.

  • WTFGuy (unregistered)

    @Wayne ref

    I have other bank stories equally stupid, which is why I won't open an account with my local bank, perhaps to share another time.

    This may or may not make you feel better, but ...

    Each of us who've worked in the innards of a company know our own particular company's product and bureaucracy is shite held together with spit & tape. By the transitive property, that means all of us who've worked everywhere know every companies' product and bureaucracies are shite held together with spit and tape.

    Changing banks won't help. Changing brands of phone or toothpaste won't help. Changing brokerages won't help. Changing ISPs won't help. It's shite from horizon to horizon and all the way down.

    And yet somehow it all sorta works. Kinda. For most of us most of the time.

  • (nodebb)

    Hex encoding instead of base64 makes actually sense since the last two characters usually are use in many other ways two. Encoding it in hex and then base64 is kinda weird, no idea what the thought process was there.

  • (nodebb)

    I remember once discovering the HMAC hashing library in Java didn't work the same as the same function in PHP. However, the PHP library produced the same output as the official, standard code and we needed them to be the same from either codebase. I ended up re-writing the top layer of the HMAC hashing in Java so it matched. The Java guy wasn't happy, but I had clear proof the Java library was wrong.

  • Old timer (unregistered)

    "Just because a payment provider is a bank" means that no-one has permission to fix anything. That doesn't always me stupid programmers, but it does mean that as soon as they get any experience they leave or are replaced by a contractor.

  • (nodebb)

    When you use a WordArray object in a string context, it's automatically converted to a hex string.

    Well it could be worse. I thought the punchline was going to be that it emitted some debug description like "Array[UInt32](length=4)"

Leave a comment on “Base of the Hash”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article