-
-
Save unrealwill/997e1486a7fa153a28679f322f8e378a to your computer and use it in GitHub Desktop.
| Tried to make a payment on aliexpress this weekend. | |
| Turns out the payment processor (wlp-acs.com), after a first valid SMS code check, is requesting my bank secret password. | |
| Didn't give it, no way I'm giving it so the payment was rejected. | |
| For information the identifier for accounts on this bank is written on every cheque you make. | |
| See screenshot below : | |
| I called the bank this morning, and they assured me this is normal that it is "required by law", they call it "second factor". | |
| #Facepalm |
@xem I had never activated Certicode Plus before. It's not the SMS verification code that it has sent me in a first step which I entered successfully. As far as I understand, it is asking for a 6-digit password. I never had any 6-digit password other than my bank password.
Sunday I activated Certicode Plus on my phone which gave me a 5-digit password. From what I understand from their documentation ( https://www.labanquepostale.fr/particulier/comptes-et-cartes/services-de-cartes/3d-secure.html )
Vous n’avez pas de smartphone ?
Nous vous proposerons prochainement une solution alternative pour valider vos paiements en ligne en deux étapes. Vous devrez :
Saisir le code de sécurité à usage unique que vous recevrez sur votre numéro de téléphone sécurisé.
Composer votre mot de passe de votre Espace Client En Ligne La Banque Postale.
Vous pouvez ensuite vérifier que votre paiement a bien été pris en compte sur le site du e-commerçant.
https://www.youtube.com/watch?v=McoYaXUo6uY
If I had activated Certicode before, it should have sent me some notification on my mobile app where I could generate a One Time Payment token using my 5 digit code.
But currently I'm still in the limbo, where I'm stuck with the old system for people that don't have smartphone so I don't get any notification nor Certicode operation in my mobile app.
Oh, thanks for the explanations. So the image you posted on top of this page showed a scam/phishing url? I may have not noticed it if it had happened to me. :|
Also, LBP's certicode is 5-digits.
@xem No, as far as I understand the sceenshot is very probably legitimate and not a scam, but from the user perspective there is no way to tell if it's a scam or not. (Technically if you use the developer tools you could see that the page contains an iframe that redirect to real url of the bank but it takes an expert eye).
The process is quite new (november 2021) and almost certainly flawed in its current implementation for the subset of people that don't use smartphones.
It is a process required by law (3d-secure) in Europe to combat fraud due to SMS not being deemed secured enough. Each bank is free to implement it its own way, and it seems labanquepostale and bnpparisbas at least got something seriously wrong from a security point of view for a subset of users (incidentally the least technically advanced ones that are also the most susceptible to phishing).
Ew, ok! Not phishing, but also not user-friendly at all. Thanks for raising these concerns.
So after activating Certicode Plus 8 days ago, 6 days ago I was still stuck with the old system, so I waited until today without any more retries to let eventual security measures wear off.
And today when I tried again I was greeted by the prompt of the new system, that tells me to watch for notification on the mobile app and enter the 5 digit-code there. And everything worked fine :)
I am no longer victim of the bug. But the bug is almost certainly still there for the majority of clients that have never activated Certicode before.
For closure, let me explain what I think is the cause of the bug, and why it's not easy to bypass and its consequences.
Because SMS was deemed insecured by law : a new process was established.
In this new process, it is safe for the payment processor whether adyen.com or wlp-alp.com or whatever to serve the request from their domains with an iframe to have the bank ask the client to verify its identity. Because the requested information is a one-time-password generated by the app (given a dedicated 5-digit code) everything is OK.
If the client has switched to the new process everything is fine. But the transition to this new process was botched by allowing the old process to persist while using the new interface.
Because it's not the bank, the payment processor has no way to know if the client has made the switch to Certicode Plus yet (By spec it should already have).
If the client has not made the switch yet, the bank inside the iframe still has to respond to the payment processor to tell him if the client is OK or not, and to do that the bank has to ask the client for some secret information only he knows (second factor) and because of simplicity it asks for the only password the client have, and this is very bad because it happens inside an iframe so the client has no way of knowing he is really speaking to the bank.
In theory what instead the bank should have done is tell the payment processor that the user has not made the switch yet and required a proper redirect from the payment processor to handle things the old way, but this was not formalized into a spec so it can't be done (because there are multiple actors).
So the next best thing would be to request a one-time password and ask the client to go and log into his bank web interface where there would be a way to generate this one time password for this transaction, but that will be too complicated for most users.
Setting-up another static password would be better than the current solution of asking the secret bank password, it would help reduce the impact of a steal (by not allowing hackers full control to the account) but won't prevent to make fraudulent payments as this secret info may be stolen easily for the same reason (the impossibility of the user to verify that he is indeed communicating with the bank).
So what the bank should do immediately is stop asking for password inside an iframe and reject the transaction until the user has migrated to the new process.
But that's probably not going to happen because most technologically adverse users that don't have a smartphone need to be able to make purchases online (even more so with the lock-downs in the recent past).
The near term consequences is an increase of online fraud resulting from purchases on small websites because users are getting trained to give their secret bank password every time they make a purchase. They won't notice when a small fraudulent website will redirect them to a fraudulent payment processor with a false iframe and gain access to their bank accounts. (If I were a cynic I would say it would benefit the security people that screwed this transition by giving them more job).
Conclusion :
To protect yourself never enter the bank password on the payment processor site and switch to the new process, and make sure your less technologically aware relatives have made the switch too.
If you have already entered the bank password on a payment processor, change it as soon as possible, and verify your account history.
@xem: The #1 rule before entering any password of your bank should be to check that you are on a domain belonging to your bank (and using HTTPS). This is teaching people to trust scam-looking server names (
https://labanquepostale-3ds-vdm.mycrappystore.cool/) for very sensitive operations.FWIW, for BNP, it appears to be the real (crappy 6-digits only) password.