-
-
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 |
I've got the same thing with another (also French) bank.
The password they"re asking for is NOT your general ebanking password. It's not your Credit Card pin code either. It's a separate, THIRD password (mine is like a CC pin: 4 digits) that's dedicated to authenticating online purchases. Mine is viewable and changeable at will in my bank app & web site.
I think it's a good idea. More 1FA than 2FA, but at least now on-line purchases do require a password, one that's not stored in each and every ecommerce site, and that we can change at any time for all sites, for example after making a purchase on an iffy site.
for bnp, they're asking for the login account password as well
this is just so crazy someone in a security team chose this method as a valid & secured 2fa auth method
When I make an online payment with ING in Romania, the processor implementing "3D Secure" redirects me to the bank's website domain, which asks me for the password. This is fine.
But from the screenshot here I see you are prompted for the password on the processor's domain wlp-acs.com. This means the processor gets my password. On seeing this I would change banks.
I confirm it's not the same password as your main bank account. (bank account is at least 6 digits, this one is 5 digits)
This system has replaced the code sent by SMS. You have to define a specific "quick" password to confirm the payment (from the web or the mobile app)
It comes from a new regulation called DSP2 https://www.francenum.gouv.fr/comprendre-le-numerique/paiements-en-ligne-lauthentification-forte-dsp2-pour-securiser-votre-site-e#:~:text=Qu'est%2Dce%20que%20la,sein%20de%20l'Union%20Europ%C3%A9enne.
@julien-lafont Nope in my case it really is the 6 digits password.
The validate button is greyed out and I can't click it :
I haven't used the mobile app ever before so I knew of only one password. And the formulation is not ambiguous it is asking for the client password.
Since yesterday I have installed the mobile app and done the certicode activation process where I picked a 5 digit number, but no-one is asking for this 5 digit number.
edit : adding the UI when I enter a 6-digit pin the Validate button gets highlighted
Le principe est simple, au moment du paiement, après avoir saisi les informations de paiement habituelles, vous vous identifiez en tant que titulaire de la carte bancaire en validant votre opération avec votre Clé Digitale (dont le code secret est identique à celui utilisé pour la connexion à vos comptes)
It's a major security flaw. It won't take long until someone write a phishing "3D secure" page and gets your password. They'll need the account number (which, AFAIK is not private, but I don't know if it's part of the data sent by the bank in the 3D secure's protocol) and then it's game over for you.
Worst: BNP is using a dumb "virtual" keyboad to log on their site (so at least, a keylogger would be useless) but a plaintext box for your account number, yet when in 3D secure mode, you'll enter your password in plain text. So a keylogger running on your computer and it's game over again (with both sites, you have everything to log in).
I've tried to contact them on their online chat, but was wonderfully answered that "it's like this, we are security experts, shut up".
I'm not even speaking of their dumb password policies like they force you to change your password, and prevent from using previous password, so you'll either end up with a password manager (good) or a dumb incrementing algorithm (like password1, then password2 etc...) which is already considered a flaw in security. Since they remember the previous passwords, in case of a data breach, they'll give the attacker a much larger attack surface, since any of the previous password will likely be useable to log in.
I don't see what's the problem. It's 2FA, not your real password (I'm at LaBanquePostale too)
@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.
@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.
I noticed the same thing happening when using the BNP bank 🤦.