Hacker News new | past | comments | ask | show | jobs | submit login

Saw this on Twitter this morning. Sounds like they must have engineered it and set things up beforehand because they (a) knew which bank he was with and (b) had everything set up ready to log in when they got his ID number and received the password reset code from his text message.

I guess one thing that could have mitigated this quicker is if the text from the bank had said "Here is the code you requested to reset your online password" instead of a generic "Your authorisation code is..."




Which bank you have is not very secret information. Any payment exposes that information.

It's a very clever scam, but it's also a very insecure bank if this is enough to authorise payment. Get a different bank that uses 2FA, makes it clear what an authorisation code is for, and doesn't call you for this kind of sensitive information.

If they really do need to reach you quickly to stop a fraudulent transaction, a simple "that's not mine" should suffice. They know they're talking to you because they're the ones calling you. If the person making that payment has also stolen your phone (entirely possible) they will not deny they made that transaction, because they want that transaction to stand. That means only confirming it's your transaction in this situation is suspicious, not denying it.


> Which bank you have is not very secret information. Any payment exposes that information.

Still, it means they had to spend some time to prepare for this specific person.

Aside - here in Europe, the account numbers including bank code is pretty much public information. Something like e-mail address. After all, you can only send something in there. To withdraw, you need login credentials.


> After all, you can only send something in there. To withdraw, you need login credentials.

Unfortunately, that's no longer true; with the SEPA Direct Debit system, money can be taken from an account with just the person's name, address, IBAN and BIC (the info required to fill a "SDD mandate"). I think there are some verifications you need to pass to be able to create direct debits, but it still seems like a move in the wrong direction, in my opinion.


All banks I had an account at required verification for any payment order, including the direct debit. Some time ago (before widespread internet banking), you could issue an order that would be verified just against the details you mention _plus your signature_.

I hope it's not possible anymore. At least my current bank lets you authorize direct debit in internet banking app. Anything you do in person requires either logging-in to the internet banking account at the branch or presenting an ID.


yes and no

as far as i know, to set up a periodic sepa transfer - at least here in SVK(EU), you need to do it in person (although more and more banks are starting to allow this through their web/phone app)

eg. issuing a sepa for my monthly ISP subscription, i put into the system that 1)from this account 2)this amount of money 3)to this exact account 4)with these aditional details/comments/etc...

and if it fails for whatever reason - in my case mostly because once in a while, the amount that should be withdrawn for that month is more than the pre-set money

- the payment gets witheld at my bank / simply fails;

- the other side contacts me via phone/mail/... that there was a failure (which i can check on my bank account, so "kinda-phishing-safe");

the other side is still able to withdraw only that specific amount once in a period (most likely a month), and if anything is amiss, the payment simply fails




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: