General Musing

blaze your trail

Posts Tagged ‘bank

A catalog of this year’s risky articles #2010

leave a comment »

Programming Hands

Risk is something which can be difficult to evaluate for the average person, there is a lot of work which goes in to learning not to do the two things that people usually do when they are confronted with risk:

  1. Ignore
  2. Overreact

It looks like every man and his dog needs to have a Facebook page, even banks…

It has been almost 1.5 weeks since Google’s FeedBurner removed the Frie…

Some days ago I tweeted to Prosper, a personal loan marketplace, whether they…

I don’t really think most people get “it” when it comes to …

Just noticed that Google Translate translates the name of the Dutch social ne…

I find a 400 plus page manual of office policies and job descriptions for eac…

In the last two days I’ve not been posting so much, and focussing on up…

I started playing with Google Scribe and wanted to see if patterns emerged so…

I have my Google account set up with English as the preferred language, my br…

For the last 2 years LinkedIn has been running a bad poor IT management depar…

When I just started I too had trouble with getting all the items I required t…

On August 11th 2007 I exceeded my GMail quota, I blogged about it here. At th…

Brian Szymanski send a reply to me concerning another bank implementing SMS b…

I don’t understand why url expansion after url shortening is such an is…

I just read an article Web Coupons Know Lots About You, and They Tell in the …

This morning/night China’s networks were sending rerouting messages to …

The lack of trained and experienced computer security people working in small…

Last week I saw an episode of a popular Dutch Ombudsman program Kassa, they r…

After seeing a program about a lifecoach trying to find the time to get his p…

Image source Radio Nederland Wereldomroep


This year’s articles about programming #2010

leave a comment »

Programming Hands

In 2010 I was less focussed on programming articles on the blog than previous years, still I have managed to create some interesting articles with code in 2010. This is an overview of the activity:

Having some fun today with QR codes, JavaScript and the Google Analytics URL …

The only questions that are asked in the Daily Scrum, aka Stand-Up, are: What…

UPDATE: GMail has introduced my number 3. YEAH! (Gmail introduces Priority In…

I like YouTube, and often subscribe to new channels and unsubscribe after a w…

Since I started working for my company I’ve been exposed to PCI DSS (Pa…

I don’t understand why url expansion after url shortening is such an is…

VeriSign – Personal Identity Portal is a OpenID provider with multiple …

Image source D’Arcy Norman

PCI is nice (or what I do) #pcidss

leave a comment »

Since I started working for my company I’ve been exposed to (Payment Card Industry Data Security Standard), “It was developed by the major credit card companies as a guideline to help organizations that process card payments prevent credit card fraud, hacking and various other security issues.1 There are only a small amount of requirements that need to be implemented, although these can be pretty substantial for some customers. I can also be difficult to understand the details of these 12 requirements for compliance.2

Being a programmer by nature I’ve often been told that the nuts and bolts of what I do, the part I enjoy, are a little complex. PCI is something different, everybody can understand that credit card data needs to be protected from unauthorized access. Not just credit card data, but all data that could potentially be used in . Which means that a policy or control needs to be implemented to control this, and note any non-compliance.

PCI is just about protecting your “Cardholder Data“:

    Primary Account Number (PAN)
    Cardholder Name
    Service Code
    Expiration Date

I know first hand that most of the banks in the Netherlands, and in most of the world, are quick to discover credit card fraud. They are also quick to payout and correct the issue for the customer, because the chance that customers will loose faith in the bank is high if they don’t. Yet ultimately these customers are still paying for all the fraud committed with all the credit cards. Banks, payment service providers or retail merchants, who have your Cardholder Data, have all the data needed for this kind of financial identity theft and fraud, and more…

It may seem obvious that this data is stored securely, credit card use is ubiquitous. Yet the large banks have had the same problems with data leakage as small retailers, which means the data must be secured from the customer right to the bank who finally processes the payment to avoid this type of leakage. The problem is that payment service providers or merchants have traditionally not done this. They may handle the temporary authorization requests for the PAN or use the (BIN) from the card number for routing the payments to the specific issuer, so they may need the number. That’s fine, as long as they store the data securely and have a log of who accessed the data and why the data was accessed.

Now that’s out of the way I can tell you what I’m doing, I’m playing with RSA [now EOL’d] and RSA . Simply put DBSM is a framework which encrypts the data as in goes into the database and decrypts it as it comes out. It’s something that anybody who is paranoid like me had already been doing for a while, but the way I was doing it required me to write custom fragments of code for every application which needed to access the data. DBSM does it transparently, while at the same time checking the users who try to access it, so only the correct users gain access. RKM hooks into this by providing a framework for the policies or controls which grants the correct people/devices/programs a key to lock-up or unlock the data, different policies can be implemented for different types of data or device.

Now you know what I do.

More reading

Originally appeared here.

Technorati technorati tags: , , , , , , , , , , , ,

  • Link openen op nieuw tabblad
  • Downloaden

Written by Daniël W. Crompton (webhat)

May 18, 2010 at 3:55 pm

More SMS banking by M&T #sms #bank #risk

with 2 comments

Brian Szymanski send a reply to me concerning another bank implementing SMS banking: M&T. Their demo, which you can find here, shows that currently you can only do balance inquiries, but it is a slippery road to implementing more features.

As I have stated numerous times before, SMS is not a secure method, even discounting the ability to snoop SMS. The sender number embedded in a sms is a 7-bit/11-byte length field containing a trailing F, specifications say this should be decimal semi-octets. What it doesn’t say, but is reasonably well known is that this is to all intents an alpha-numeric field which is set by the sender. This mean using this field you can spoof the sender, and using blind spoofing you may be able to fool the bank into performing a transaction. And if you are like many people you will not type the phone number when you reply you will reply to the message, so there is a possibility to blind spoof the user into performing a transaction or sending you transaction data. Which leaves the possibility of data leakage. Add that to the fact I can get the messages out of the air, and can either decrypt them or make rainbow tables[1]. There are so many attack vectors in SMS banking that I believe it’s not secure.

From GSM service security:

GSM uses several cryptographic algorithms for security. The A5/1 and A5/2 stream ciphers are used for ensuring over-the-air voice privacy. A5/1 was developed first and is a stronger algorithm used within Europe and the United States; A5/2 is weaker and used in other countries. Serious weaknesses have been found in both algorithms: it is possible to break A5/2 in real-time with a ciphertext-only attack, and in February 2008, Pico Computing, Inc revealed its ability and plans to commercialize FPGAs that allow A5/1 to be broken with a rainbow table attack. The system supports multiple algorithms so operators may replace that cipher with a stronger one.

If they stick to balance inquiries then it can be an acceptable risk, I even do balance inquiries using MSN with my bank, and this only slightly better security wise.

  1. Research May Hasten Death of Mobile Privacy Standard

Written by Daniël W. Crompton (webhat)

April 22, 2010 at 12:33 pm

Posted in business, finance, risk

Tagged with , , ,

Banks don’t understand Privacy #privacy

leave a comment »

I was approached by a recruiter for a role as PKI specialist for a Dutch bank. They asked me to send them a copy of my passport over the internet. They wanted to forward this to the bank. According to the recruiter this was normal practice for them and the bank.

Interestingly enough when I had privacy concerns they thought I was making a big deal about nothing. This is the recruiter for the Triple-A rated Dutch bank, who I’ve mentioned in my blog before. I refused to send a copy of my passport over the internet, and told the recruiter that I would need some assurance that they would not send it over the internet.

Technorati Tags: , , , ,

Written by Daniël W. Crompton (webhat)

September 7, 2008 at 7:39 pm

Posted in pki, privacy, risk, security

Tagged with , , , ,

From e-Gold to Payment Systems (Update) #finance

leave a comment »

Written by Daniël W. Crompton (webhat)

July 28, 2008 at 4:01 pm

Posted in business, finance

Tagged with , , , ,

Reserve Bank of India halts mobile payments #risk

with one comment

I mentioned the insecurity of mobile payment systems before in Rabobank has insecure SMS banking. Apparently the RBI has the same reservations I do. In the article RBI puts a temporary halt on Mobile Payment Services explains.

They haven’t stopped regular services such as requesting bank balance, but they have halted signing off on permitting projects to go life until the final guidelines have been issued, micropayments and larger transactions.

From the draft guidelines:

It is suggested that the banks issue a new mobile pin (mPIN). […] Banks and the various service providers involved in the m-banking should comply with the following security principles and practices with respect to mPIN : […]
Protect the mPIN using end to end encryption

They don’t seem to require One Time Passwords, which I would certainly have as a requirement, and I hope they don’t consider A5 to be end-to-end encryption. Nokia and Visa already started working on a secure payment system in 2007 using RFID.1

Technorati technorati tags: , , , ,

Written by Daniël W. Crompton (webhat)

July 26, 2008 at 5:53 pm

%d bloggers like this: