Stealing credit card details via NFC is easy/pointless

That might just be a netbook in his pocket

A US TV station has demonstrated how easy it is to lift credit card details from proximity-payment cards, though in the process showing just how pointless the activity is.

The video does a nice job of demonstrating just how close you have to be to read a card, which are induction-powered so have very limited range; you needn’t worry about the chap walking behind you, but tube travellers might be concerned about the one pressed against them… But with typical hyperbole, the channel fails to point out the limited risk such reading presents.


The attacker is shown reading the card number and expiry date, which the presenter interprets to mean that 140 million credit card users are at risk, and goes on to ask why the credit card companies aren’t doing anything about it.

The reason, of course, is that the risk isn’t significant, at least not yet. Remote readers can’t pick up the CCV code, which is on the back of the card (the three digits on the signature strip), or the card holder’s address – both of which will be required for any online transaction.

So could sniffing the card allow the criminal to create a clone of the card sniffed, then use it at a contactless pay point? Probably, though it would be difficult and not risk-free for the criminal – proximity payments are only used for small-value transactions, and will ask for a PIN at random (which the criminal won’t have) as well as leaving a detailed paper trail. Such a card would only work for offline payments, where no challenge-response mechanism is used, and while such things are permitted by the standards, their use could easily be reduced if it became a problem.

So if you notice the stranger behind you shuffling too close, they’re more likely trying to cop a feel than to wirelessly pick your pocket: there are a lot more perverts than technically-proficient thieves prepared to go so far for the price of a cup of coffee.



Someone that have a different vision of what i think about the future…



Tokens vs tokenless

two-factor authentication



12 February 2010

These days, it is widely accepted that two-factor authentication (2FA) is essential to secure remote access to sensitive information on the corporate network. And with the increase in remote and home working for greater flexibility, a better work/life balance and cost savings, the demand for 2FA is on the increase.

Once the decision has been made to deploy 2FA, the next question is whether to go for a solution based on hardware tokens or opt for a tokenless approach that makes use of mobile phones. Vendors that offer only a tokenless solution would have us believe that tokens will soon be replaced by tokenless authentication, which has led to much debate about the pros and cons of each. But is it really a case of one or the other?

Dedicated tokens – such as those produced by market leaders RSA – provide a one-time passcode, typically every 60 seconds, and have been the traditional approach to 2FA for many years. However, more recently, the introduction of tokenless solutions has been hyped, mainly due to their ability to deliver one time passcodes on demand to a standard mobile phone or smartphone such as the popular Blackberry. After all, most people already carry one of these devices with them, most of the time.

A tokenless solution therefore eliminates the need to carry a separate piece of hardware – albeit usually attached to a key fob – and reduces the costs and time associated with provisioning new and replacement tokens. Sounds ideal; but it’s not the full picture and the simple truth is that tokens remain the best solution for frequent users who rely on getting secure remote access to systems and information from any computer at any time.

Road warriors, home workers or systems engineers, for example, often log into many different portals every day and requesting or obtaining passcodes from a mobile phone or PDA is far too much hassle.

What’s more, tokens are not limited to a particular platform such as Windows and are not reliant on how secure a mobile phone network is, good network coverage or the battery life of the phone. They are also more robust. RSA tokens will work even if dropped from a great height or it they fall in a glass of water. The same is not true of the mobile phone.

It is much easier and reliable for frequent users to carry a token that automatically and continuously generates passcodes for immediate access. And when it comes to cost; frequent users can quickly run up SMS charges for requesting passcodes from a mobile phone or PDA.

But this is not to say there isn’t a place for tokenless authentication; it is ideal for infrequent or temporary users and for those that simply do not want to carry a separate device. As it requires an additional request stage, tokenless authentication is best suited to occasional users, contractors, part-time staff and those checking email from home, for example. It can also provide temporary Extranet access to other departments, professionals and partners or for sensitive online services such as HR, e-commerce or access to health information. Having short term remote access to the corporate network is also valuable in emergency scenarios as a result of bad weather, strikes or terrorist treats, for instance.

The reality is that it’s a case of ‘horses for courses’, depending on the organisations, the user’s working requirements and the data and applications they are accessing. In fact, for most organisations the question shouldn’t be which option to go for, but what combination of token and tokenless 2FA they need.

The ability to mix both token-based and tokenless two-factor authentication within an organisation means that authentication can be tailored to meet specific needs, budgets and working patterns. But, having realised the benefits of deploying both token and tokenless 2FA, the problem organisations will face is that most two-factor authentication vendors will only offer one or the other.

By deploying two-factor authentication as a hosted service, this hurdle is eliminated by removing all the hassle of setting up, deploying and managing both a flexible token and tokenless two-factor authentication solution. Using a cloud-based service means that organisations can reap the benefits of both options and choose the right authentication based on specific users’ needs. In addition, a hosted authentication service delivers proven security and guaranteed reliability along with a lower total cost of ownership. And when it comes to tokens, it removes any of the complexities and logistics of deploying the tokens, ensuring fast, reliable and flexible service delivery.

So yes, the death of the token is greatly exaggerated. Through the delivery of 2FA as a service in the cloud, tokens will always remain the most reliable choice for many users. While the battle between the token or tokenless vendors suggests that customers have to choose one or the other, the simple truth is that organisations need to take a flexible ‘best of both’ approach that meets the requirements of different types of user.


Is oauth 1 obsolete now and I should be implementing oauth 2?

Eran Hammer-Lahav has done an excellent job in explaining the majority of the differences in his article Introducing OAuth 2.0. To summarize, here are the key differences:

More OAuth Flows to allow better support for non-browser based applications. This is a main criticisim against OAuth from client applications that were not browser based. For example, in OAuth 1.0, desktop applications or mobile phone applications had to direct the user to open their browser to the desired service, authenticate with the service, and copy the token from the service back to the application. The main criticism here is against the user experience. With OAuth 2.0, there are now new ways for an application to get authorization for a user.

OAuth 2.0 no longer requires client applications to have cryptography. This hearkens back to the old Twitter Auth API, which didn’t require the application to HMAC hash tokens and request strings. With OAuth 2.0, the application can make a request using only the issued token over HTTPS.

OAuth 2.0 signatures are much less complicated. No more special parsing, sorting, or encoding.

OAuth 2.0 Access tokens are “short-lived”. Typically, OAuth 1.0 Access tokens could be stored for a year or more (Twitter never let them expire). OAuth 2.0 has the notion of refresh tokens. While I’m not entirely sure what these are, my guess is that your access tokens can be short lived (i.e. session based) while your refresh tokens can be “life time”. You’d use a refresh token to acquire a new access token rather than have the user re-authorize your application.

Finally, OAuth 2.0 is meant to have a clean separation of roles between the server responsible for handling OAuth requests and the server handling user authorization.


Cracking 14 Character Complex Passwords in 5 Seconds

There has been a lot of talk recently in the security community about high speed GPU (video card) processors being able to crack passwords very quickly.

But there is a technology that can crack them even faster. A Swiss security company called Objectif Sécurité has created a cracking technology that uses rainbow tables on SSD drives.

Apparently it is the hard drive access time and not the processor speed that slows down cracking speed. So using SSD drives can make cracking faster, but just how fast?

One article in March of this year stated that the technique using SSD drives could crack passwords at a rate of 300 billion passwords a second, and could decode complex password in under 5.3 seconds. So, how long would a long complex password hold up to the SSD based cracking technology?  

Sounds like we need to put this to the test. Most hackers will crack passwords by decoding the password hash dumps from a compromised computer. So,  I pulled several 14 character complex passwords hashes from a compromised Windows XP SP3 test machine, to see how they would stand up to Objectif’s free online XP hash cracker. The results were stunning.

Let’s start out with an easy one. Here is the Administrator password hash from the machine:


And putting this into Objectif’s tool we get this response:

Password: Empty password…    
Time: 2 seconds

Administrator didn’t set a password, that’s not good…

Okay, that wasn’t 14 characters, let’s try a hard one.

How about this one:

Hash: 17817c9fbf9d272af44dfa1cb95cae33:6bcec2ba2597f089189735afeaa300d4

And the response:

Password: 72@Fee4S@mura!    
Time: 5 Seconds

Wow! that took only 5 seconds and that is a decent password.

Let’s try a few more:

Hash: ac93c8016d14e75a2e9b76bb9e8c2bb6:8516cd0838d1a4dfd1ac3e8eb9811350
Password: (689!!!<>”QTHp    
Time: 8 Seconds

Hash: d4b3b6605abec1a16a794128df6bc4da:14981697efb5db5267236c5fdbd74af6
Password: *mZ?9%^jS743:!    
Time: 5 Seconds (Try typing that in every day!)

And Finally:

Hash: 747747dc6e245f78d18aebeb7cabe1d6:43c6cc2170b7a4ef851a622ff15c6055
Password: T&p/E$v-O6,1@}    
Time: Okay, this one really pushed it to the limits, it took a whole 11 seconds to crack!
(* Ran it through a second time later on and it got it in 3 seconds!)

Very impressive, it took only five to eleven seconds in this test to crack 14 character complex passwords. I was able to create a password that Objectif’s site couldn’t decode; it was using characters from the extended ASII set. But, unfortunately, I could not log into the XP system using it either. 

Want to see how a password would do without having to exploit a system and dump the password hashes? Objectif allows you to put a password in and it will convert it for you. Then you can place the hash into the cracker and see how it does.

Granted, these are Windows LM Hashes and not the more secure Windows 7/ Server 2008 NTLM based hashes. But, I believe that with cracking speeds increasing, relying on passwords alone may no longer be a good security measure. Many companies and government facilities are moving away from using just passwords to dual authentication methods. Biometrics and smartcards are really becoming popular in secure facilities. 

And if the rumors are true, it looks like Microsoft may include facial recognition authentication in the next version of Windows. Time to dust off the old Web Cam…


How RSA Security Token Quality Compares to Vasco

How RSA Security Token Quality Compares to Vasco

A test-by-test comparison of the RSA SecurID® SID700 token to the Vasco Digipass®Go 3 token

Durability is defined as the capability of withstanding wear and tear and theability to perform or compete over a long period.  When putting a technologydevice into the hands of end users, IT departments and line-of-businessmanagers need to have confidence that the device will perform regardless ofthe rigors of the end user environment. Hardware failure decreases workerproductivity and increases help desk costs, as well as creating greater end userfrustration. Durability and reliability are non-negotiable requirements in thedeployment of any hardware device.Recently, In order to assess the durability and reliability of two leadinghardware token types, RSA Security employed an accredited, independentthird-party testing firm, National Technical Systems, to compare the RSASecurID®SID700 token to the Vasco Digipass®Go 3 token across a set of eighttests. This paper discusses the tests and their results.

I. INTRODUCTIONWhen an organization makes a decision to implement aone-time-password solution using hardware tokens, theywant to be sure the solution meets the highest standards.Above all else they want to avoid the problems associatedwith poor token quality. Tokens that fail while in the handsof end users generate needless expense, a decrease insecurity and a loss of confidence in the solution.For years RSA Security has been committed to the highestlevel of quality in their tokens. RSA Security routinelyconducts a series of quality tests on its tokens. The tests aredesigned to simulate the extreme conditions to which atoken may be subjected over its lifetime.RSA Security has been able to directly correlate that tokenspassing these tests will meet the requirements of the fieldfor five years or even longer. A detailed description of thetests can be found on the RSA Security website in the paperEnsuring Token Reliability Across the Enterprise.http://www.rsasecurity.com/products/securid/whitepapers/SIDREL_WP_0505.pdfNational Technical Systems conducted eight separatecomparison tests on the RSA SecurID token and the Go 3tokens including: temperature cycling, high humiditytolerance, vibration, shock, immersion check, run-overcheck, electrostatic discharge and tumbling. Each test wasdesigned to simulate real world conditions. This paperoutlines the results of the comparison tests.Of the eight tests conducted, RSA Security passed all eighttests while Vasco failed to meet the standard in six separateinstances.

II. TESTS AND RESULTS1.  Random VibrationThe  Random Vibration Test is designed to simulate thevibration a token could be subjected to while beingtransported or shipped. The test consists of placing thetokens into an electromagnet shaking device andsubjecting them to an acceleration of 15 Grms with afrequency of 10-2000 Hz with a duration of one hour pereach of three axis (X, Y & Z). Ten tokens of each brand weretested. EQUIPMENTT1000A Electromagnetic ShakerTEST STANDARDA failure rate of less than 1% deemed acceptableRESULTSRSA SecurID token: all passedVasco token: 4 Failures (40% of the units rendered inoperable)

2.  Mechanical ShockThis test is designed to determine if a token could survivedrops from high places as well as unexpected jolts. Shocktesting is used to verify that the device can survive asudden impact. The test consists of placing the tokens in ashock fragility tester and placing the units under a stress of3500 Gs with a pulse time of 0.5ms on all 3 axis of the unit.Two units of each token type were used in this test.TEST STANDARDNo failures RESULTSRSA SecurID token: all passedVasco token: 1 Failure (50%—the digital display cracked)3.  ImmersionThe immersion test is designed to see how a token willreact when it has been submerged in water for a period oftime. A token can be exposed to water when it isinadvertently sent through a wash cycle or when droppedinto a pool or sink. In this test tokens were placed 1 meterbelow the surface of a tank of water for two hours andchecked periodically. Two tokens of each manufacturerwere used in this test.TEST STANDARDNo failuresRESULTSRSA SecurID token: all passedVasco token: 100% Failure (Note: the Go 3 displays filledwith water and failed within 5 minutes.)

4.  Run-OverTokens are often dropped and are susceptible to beingstepped on or even run over by a vehicle. The run-overcheck is designed to test ruggedness when such an incidentoccurs. In this test the RSA SecurID tokens and the DigipassGo 3 tokens were run over one time with the driver’s siderear tire of a Dodge Durango XLT. Two tokens of each typewere used in this test. TEST STANDARDNo failuresRESULTSRSA SecurID token:  all passedVasco token: all failed (both Go 3 tokens had cracked LCDsand were missing display digits)5.  Temperature CyclingTokens are often subjected to extreme temperaturechanges. A token could be left in an enclosed automobilein the desert heat or overnight in the middle of a coldwinter. Temperature changes in the cargo hold of anairplane during assent or descent could also test the limitsof any device. To simulate these conditions the testincluded placing tokens into a temperature chamber at -0°Cto 70°C for 25 cycles with each cycle taking 2 hours and 1.5hours for ramp time. Thirty of each type token were usedin this test.TEST STANDARDNo FailuresRESULTSRSA SecurID token: all passedVasco token: failed (1 failure – speckling of digit in the display)

6.  TumblingKey fob tokens are designed to be attached to a key ringwhich is frequently carried in a pocket or purse. This testsimulates the token’s environment inside a pocket. Tokensare placed in a tumbling drum along with twenty blankkeys and five quarters, five dimes, five nickels and fivepennies and turned at 20 RPMs for 60 minutes. Two tokensof each type were subjected to this test.TEST STANDARDNo FailuresRESULTSRSA SecurID token: all passedVasco token: all passed7.  High HumidityHigh humidity testing is designed to simulate use of thetoken in places where there are typically humid conditions(e.g., Florida, Hawaii, Asia Pacific). Even if the users are notbased in such a location, they often travel and the tokenmust be able to withstand such conditions. This testincludes subjecting the tokens to 95% relative humiditywith 35°C for 96 hours. Ten tokens of each type were used.TEST STANDARDNo FailuresRESULTSRSA SecurID token: all passedVasco token: all passed

8.  Electrostatic DischargeIn dry climates, especially during winter months, tokens areoften subjected to electrostatic discharge. This can occurwhen exiting a car or simply by walking across a carpet andthen touching a metal surface. The test is designed tomeasure a token’s resistance to the resulting shock when“zapped” by a gun designed to deliver +/-20 kV discharges.As this is a relatively common occurrence, fifty units of eachmanufacturer’s tokens were tested.TEST STANDARDLess than 1% failureRESULTSRSA SecurID token: all passedVasco token: 14 Failed (28% – Note: 13 Vasco units displayed all zeros following the test and one would not turn on at all.)SUMMARYThe Vasco tokens failed to meet the defined standard in sixof eight (75%) of the cases while every RSA SecurID tokenpassed every test.While it is nearly impossible to predict the environmenttokens will be subjected to, it is almost certain they will beexposed to adverse conditions at some time over their lifecycle. A durable, reliable token solution from RSA Securitysaves time, aggravation and money



Google Apps con autenticación móvil, mejorando la seguridad – iPhone, Android, BlackBerry

Los que utilizamos los servicios bancarios por internet estamos acostumbrados a tener doble autenticación para realizar cualquier transacción. La primera es usando la clave y la segunda mediante un código de seguridad enviado a los dispositivos móviles.


Pues bien, Google ha decidido incrementar la seguridad de Apps de forma similar al sistema bancario.

A partir de ahora los administradores de cuentas Google Apps tienen la opción de desplegar una segunda capa de seguridad en todas las cuentas de Google Apps de las ediciones Premiere, Education, y Government.

La primera capa de seguridad es la autenticación normal que ya todos conocemos (usuario y clave) y la segunda es a través de un código de verificación enviado al dispositivo móvil del usuario (mensaje de texto y mensaje de voz). Simple, sencillo y barato para las empresas!

Los administradores de Google Apps pueden configurar y activarlo a través del panel de control.

Los usuarios luego de iniciar sesión deberán solicitar el código de verificación a través del botónGet a new verification code” (de no ser recibido automáticamente), ingresar el código en la casilla correspondiente y si el equipo desde donde inician sesión es seguro pueden marcar la computadora como un dispositivo seguro para no volver a introducir nuevamente un código de verificación
Google Apps verification code

Todo esto significa que a pesar de que te roben la clave nadie podrá ingresar a tu cuenta debido a que es necesario tener el móvil a la mano.

Para los móviles basados en Android, blackberry y iPhone se ha creado la aplicaciónGoogle Authenticator
Google Apps verification code 1

Si sumamos el cifrado HTTPS, la certificación FISMA obtenida por Google y una clave segura con mayor cantidad de caracteres… ya no existe pretexto para no migrar a la nube!

… bueno, la confidencialidad es otro problema a resolver.

Nota: los usuarios de la edición estándar podrán disfrutar de esto en los próximos meses.



CRITIX READY certification: PINsafe by Swivel Secure



PINsafe is designed to combat threats ranging from skimming, phishing and spyware to shoulder-surfing, key-logging.  Its unique combination of registered PINs and randomly generated security strings delivered simply to the user makes it the safest, easiest and most reliable and cost-effective authentication solution available.

PINsafe has a full range of user interface options, including mobile and image based authentication models, all included in the licence.  The different user interface options can be assigned to different users based on corporate security and access policies.

With no tokens to manage, PINsafe allows for instant provisioning (and deprovisioning) of end-users.  By removing the cost of individual tokens and the associated administration and management overheads, the overall budget requirements for implementation is reduced as are the ongoing management costs.

With flexibility built into its architecture for easy implementation, PINsafe is designed to accommodate the unique requirements of each individual organization.

  • Users can be added and removed by managing the existing user repository or repositories (eg Active Directory). Provisioning becomes part of the existing account creation process
  • User-defined PIN composition and PIN change policies can be set
  • Self-care options include PIN change and PIN reset
  • Comprehensive logging options
  • Can be deployed as software only or on a single or multiple Appliances
  • Scalable application

A single PINsafe server can provide the authentication for all your remote services, VPNs, Websites and Web Applications. For more information on PINsafe