Banks simplify access to our bank accounts. They keep relaxing security while hoping to replicate the boiling frog story. The trouble is that no-one dies and someone will figure out – sooner rather than later.
I touch on a few things: using online banking to find valid card numbers, and date of birth, increasing chances for unauthorised access, lowering security of login credentials and changing role of debit cards.
Tokenisation is a hot topic as it makes card processing cheaper and more secure. The goal is to replace your card number with a random number that is hard to use for unauthorised transactions – and it removes the need to encrypt databases.
What we are primarily looking at now are mobile payments but we are designing solutions for e-commerce as well. Payment processing involves re-encryption of PINs (PIN-blocks) for card-present transactions.
Our emails were not being delivered. I thought it was just my ignorance but a chat with a few more people around told me it was not the case. This is a story of a geek learning a (yet another) lesson the hard way.
We have recently come across a nice check-list for whoever wants to use DNSSec and establish a good security baseline with a hardware security module (HSM), i.e., never get encryption keys compromised.
We are now integrating encryption into a corporate infrastructure and it made me think about payments and PCI audits. PCI stands for Payment Card Industry. Anyone who got close enough to e-commerce, or card payments knows what a burden it is on running a business.
Sooo, I have spent some time this week thinking about architectures for “technical security systems”. I could say “cryptography” straight away, I guess. Thinking about protecting sensitive data that may be subject of independent audits.
The scope of PCI audits is given by storage and processing of credit card numbers and PINs (in case of Chip&PIN systems). Once you experience the pain, you definitely want to get “out of scope”. This is true for merchants just as banks.
We started researching options for introducing our encryption system to Amazon AWS. We seem to have lost the first round (request declined) as Amazon SaaS does not square up with our Enigma Bridge CloudHSM servers. But they offered a chat to figure out options – talking is always good!
My company Enigma Bridge built a truly scalable (in all meanings of the word) hardware platform (with FIPS140-2 Level 3). OK, you have no idea what I talk about… that is one of our communication problems.
How can we explain to people what is the advantage of using tamper-resistant hardware. What is the advantage of hardware separation – something our platform provides even when packaged as a cloud service.
Photo: SplitShire (yes, it’s 1/2 litre of one of the big brands – not a pint of a local real ale)
The chances are that this is the first time you’ve seen the OTP acronym. OTP is one of possible replacements of static passwords. Instead of remembering your password, you need to have a device that will compute a new OTP code each time you want to log on to a server. You will also need a different OTP “generator” for each server or web service that uses OTP and you will most likely still have to enter your password (or a shorter PIN) as well.
One time passwords are short numeric strings of a fixed length. Each time you want to log on somewhere with OTP, the string you enter will be different. The OTP string would change with the time or after each time you use one OTP value.