MEPs back caps on card fees across the EU

The fees that banks charge retailers for processing shoppers' payments should be capped, Economic and Monetary Affairs Committee MEPs decided in a vote on Thursday.

Banks' card payment fees cost EU retailers over €10 billion each year, according to the European Commission figures.

In a statement, the Committee says: "These fees are not transparent and they differ between EU member states, where they are subject not to legislation but to decisions by national competition authorities."

In today's vote, MEPs backed the European Commission's proposal to cap the bank's fee at 0.3% of the transaction value.

For debit card transactions, the committee amended the proposed cap to seven euro cents, or 0.2% of the transaction value, whichever is the lower.

These caps would apply to both cross-border and domestic transactions in the EU and would take effect one year after the rules enter into force.

Under the new rules, retailers would also be free to choose which cards to accept, unless they are subject to the same interchange fee which, moreover, must comply with the cap set by these rules.

The rules will be put to vote by a full house at one of the upcoming parliamentary sessions.

E-Payments: ECB supports revised legislation for electronic payments

02-13-2014


E-Payments: ECB supports revised legislation for electronic payments

On 10 February, the European Central Bank published its legal opinion on the European Commission’s proposals for a revised Directive (PSDII) that aims to regulate the European Market for electronic payments. The ECB strongly supports the objectives of the proposal as it aims to widen the list of services to include payment initiation services and account information services.

The ECB supports the measures proposed as it believes it will foster innovation and competition in retail payments. The developments in the European e-commerce landscape have played a role of importance in the ECB’s decision.

Payment initiation services are those in which a third party provider (TPP) initiates a payment at the request of the payer. It features often in online purchases as an alternative to credit card transfers. Account information services are able to provide consolidated information on different accounts that might be held by one individual, helping to provide a comprehensive view of its financial situation.

Reacting on the statement by the ECB, Paul Alfing, Chair of the e-Payments Working Committee of Ecommerce Europe, states that: “We warmly welcome the proposals to reform the European payments industry. Third party providers can accelerate product development and foster cross-border competition, contributing to a true Digital Single Market. For consumers, more competition should make the payment process more transparent and it should result in less additional costs”.

The full text of the ECB’s opinion is found here.

BBVA WALLET & SEGURIDAD

BBVA Wallet es una nueva aplicación que ha llegado a las plataformas de iOS y Android hace pocos días. Es la primera cartera virtual en España que te ofrece realizar pagos desde el móvil utilizando tecnologías como son NFC y Contactless. La aplicación nos permite realizar pagos desde nuestras tarjetas almacenadas en nuestra “cartera virtual” de una forma fácil y “segura”. No estoy de acuerdo con la afirmación de que la aplicación essegura por eso en esta entrada explicaré brevemente porque la aplicación no es segura y las opciones que tienen los desarrolladores encargados de esta aplicación para añadir capas extras de seguridad a la aplicación.

Configurando nuestra zona de pruebas

• En mi caso personal estoy utilizando como conejillo de indias a mi iPad mini (iOS 7) con la última versión de la aplicación (2.4.1203). La aplicación no tiene interfaz nativa para iPad pero funciona perfectamente en el dispositivo.
• Después de haber descargado la aplicación utilizo el proxy Charles para poder redireccionar todo el tráfico desde mi iPad a mi ordenador y así ver como funciona la aplicación móvil mediante un ataque Man-in-the-middle, quedando así la estructura de la red:

Hasta aquí tenemos el ambiente creado para analizar los paquetes que se mandan entre la aplicación de BBVAWallet y el servidor remoto.

Realizando el análisis

• En la primera prueba que realizo me doy cuenta que la aplicación utiliza HTTPS para todas las peticiones.

HTTPS No es la solución

No me malinterpreten, HTTPS es seguro de por si pero si no lo implementan bien tanto en el lado del cliente como en el servidor es como si fuera una capa de seguridad nula. Si vemos la siguiente imagen comprobaremos como no podemos ver la información que se envía mediante cliente-servidor:

El gran problema de la aplicación de BBVA es que no comprueba que el certificado que le enviamos desde el servidor sea el correcto, simplemente les basta con conectarse mediante HTTPS que no es lo recomendado ya que el usuario ha podido instalar en su teléfono móvil el certificado del atacante así que todas las comunicaciones quedarían expuestas y veríamos la información en texto plano como muestra la siguiente imagen:

Este tipo de ataques se pueden evitar mediante la utilización de métodos  SSL Pinning que evitan hasta cierto punto que se produzcan los ataques de tipo MITM, hay dos artículos muy interesantes que explican como utilizar estos métodos en aplicaciones iOS.

• El primero es un artículo de Jay Graves que me encontré en la página de doubleencore.com que nos dice como podemos implementarlo en las aplicaciones que utilicen NSURLConnection para sus conexiones.
• El segundo no es exactamente un artículo dedicado a estas funciones pero nos explica bastante bien como podemos evitar que nos hagan este ataque utilizando la clase AFNetworking. Podemos encontrarlo en la página de Miguel Diaz Rubio escrito por Sendoa Portuondo.

Un poquito más…

Al ser BBVA una entidad bancaria me imagino que se gaste mucho dinero en proteger la seguridad de sus clientes y crear aplicaciones que utilicen las ultimas tecnologías para proteger la información de las cuentas de los usuarios pero….NO ES ASI.

No conforme  con lo que había visto hasta el momento me atrevo a introducir mi información personal para utilizar la aplicación de BBVA (Si, soy cliente de BBVA). Digo yo que al menos esta información la cifrarán con algún súper algoritmo estilo AES…que equivocado estaba…Todos mis datos (NIE, Contraseña) se envían en texto plano.

Ya no es solo que no comprueben los certificados sino que están exponiendo toda mi información personal a cualquier hacker que tenga unos conocimientos medios de informática. Pero la cosa no queda ahí, no, no..Hay más, mucho más. La respuesta a esta petición del cliente nos devuelve nuestro nombre y apellidos  bien bonitos acompañado de un hash de nuestro documento de identidad (que bueno que son estos desarrolladores, cuidando siempre de nuestra información) y como no, en texto plano:

Ahora si que me han dejado pasmado, pero todavía queda un poco más. Un par de notitas para los desarrolladores de la aplicación de BBVA Wallet.

• No confíes en nadie, comprueba todos los datos que se envían.
• Es absolutamente necesario comprobar el CA (Certification Authority) este expedido por una entidad válida. Si no es así, no seguimos con la conexión.
• Encripta toda la información, en serio, TODA!!!
• JSON Mola más.

Lo que queda:

Ya para acabar de destrozar la aplicación estos desarrolladores tan molones decidieron que era buena idea mostrar la información de las tarjetas de crédito/débito y como no, en texto plano también:

Ver Fuente