Posts Tagged ‘encryption’
Encrypted Disks #security #privacy
 |
Encrypted Disk
I just saw this question: I have an external 3Tb Hard drive formatted as Mac OS Extended (Journaled, Encrypted) with 10.7.1. Just wondering if 10.6 can also access this external hard drive ? And saw this answer: I strongly recommend against encrypting anything unless you really really really have to. The only one it will ultimately keep away from your data is yourself.  It’s stupid answers like this that allow people to lose their identity when their phone, computer or harddisk is stolen. By encrypting your data you are wisely protecting your data from theft, and ensuring that when you do suffer the loss of a device you don’t compound that loss with your identity or other valuable data. It is in exceptional circumstances that you lose your data due to the encryption, this is not likely to happen.
The first thing I do on my computer is set up an encrypted disk, you should too.
Image source: Sebastian Fritzon
|
 |
6 Months of Security Links #2011
I’m a regular curator of daily links, and like to give overviews of my collection of curated links and posts. This is partly as there are some good sources and articles in here and as I am working on a research project which I started based on a number of books I read.
I’m sure you’ll find something interesting in the items below – there are some gems in the list – and I dare to hazard the guess you might learn something you wanted to know. 🙂
This year’s articles about programming #2010
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:
Sync Web with Phone #html #javascript #scratchpad
Having some fun today with QR codes, JavaScript and the Google Analytics URL …
The Structure of a Daily Scrum #agile #scrum
The only questions that are asked in the Daily Scrum, aka Stand-Up, are: What…
Features I Still Miss in Mail #mail #email
UPDATE: GMail has introduced my number 3. YEAH! (Gmail introduces Priority In…
YouTube Channel Unsubscribe #bookmarklet
I like YouTube, and often subscribe to new channels and unsubscribe after a w…
PCI is nice (or what I do) #pcidss
Since I started working for my company I’ve been exposed to PCI DSS (Pa…
Solving the URL shortening problem #twitter #tweet
I don’t understand why url expansion after url shortening is such an is…
VeriSign PIP Browser Certificate workaround (PIN Request) #identity #openid
VeriSign – Personal Identity Portal is a OpenID provider with multiple …
Image source D’Arcy Norman
PCI is nice (or what I do) #pcidss
Since I started working for my company I’ve been exposed to PCI DSS (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 identity theft. 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“:
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 Bank Identification Number (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 Database Security Manager [now EOL’d] and RSA Key Manager. 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 tags: pci, dss, payment, industry, rsa, rkm, dbsm, encryption, standard, bank, merchant, retailer, ecommerce
Reserve Bank of India halts mobile payments #risk
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 tags: risk, business, mobile, payment, micropayment
Rabobank has insecure SMS banking
The Rabobank has a new service called Rabo SMS Betalen, the purse can be accessed by SMS.
- Alice sends a message to 6689 with the phone number and amount in the body, either +316-<number> or 06-<number>
0612345678 15 Thanks for the money, Bob.
- Alice receives a confirmation SMS from 6689 with an OTP (One Time Password)
- Alice sends the OTP back by SMS to 6689 confirm the transaction
- Bob, the recipient, receives a confirmation SMS from 6689 that money has been transferred from Alice’s phone number
There are a number of issues with this, primarily that it is possible to perform a man-in-the-middle attack on this system with less than $1000 worth of equipment.
From GSM 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.
I wonder who sold them this idea?
technorati tags: bank, encryption, payment, mobile, sms, gsm
