Just came across a really good presentation exploiting some (inexcusable) vulnerabilities in N26 - check it out: https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money
However despite this, I would personally still trust it for two reasons, 1) the attacks require intercepting the access token from an existing, paired device 2) the bank is still liable for all the fraud at the end of the day, so as an user I couldn’t care less.
You’ll also notice at no point the PIN/TouchID or lack thereof is an issue, as clearly it makes absolutely no difference when the attacker has physical access to your device. 
6 Likes
Wow 
Some of these vulnerabilities really are inexcusable.
No API limiting?? I can’t believe he managed to brute force the sms token.
And unbelievable that the email/password reset response contains everything you need to reset. Terrifying. 
To me the reset token being in the response (instead of the email) is the most inexcusable one - it defeats the whole purpose of the feature. The reason why you’re sending it via email is because you don’t trust the client, so why the hell are you sending it to the client to begin with?
Yeah definitely. There is literally no reason ever that the token should be sent to the client. I can’t imagine what an engineer was thinking to add it to the response.
Very strange stuff.
1 Like
Now that I think of it, could be a stupid idea of validating the code on the client, to give a “responsive” UI instead of waiting for a server request.