Send dosh (insecurely) via email, Jack Dorsey's Square tells punters Not content with revolutionising shopping as we know it, uber-cool money-transfer outfit Square has launched a peer-to-peer payment system – secured only by an SMTP password. Square – the payment firm developed by Twitter founder Jack Dorsey – has debuted a new service, Square Cash, which authorises transactions with an email …
Forging an email is a doddle, and TLS with authentication has nothing to do with making it harder. You can run an MTA on your own box if you honestly can't find some other MTA to send mail through. Even in your mail client you can set your name and email address to be different from your username/password when you do use authentication.
Of course, the recipient might have half decent filters on their mail servers that will check HELO addresses and reverse DNS and all that, but it possibly still won't bounce the message even if it looks suspicious because of all the false positives from badly configured MTAs out there.
The recipient could manually check the headers for a suspicious email, but I doubt there are many people that do that. So a lot of people won't notice that an email's forged unless (like most phishing attempts) the content of the email is obviously not genuine.
SMTP is how you send outgoing emails, but it's also how the mail servers transfer emails between themselves. You may need log into your mail server to send mails, but only when sending to domains not hosted on that server (i.e. when relaying).
If it's the host server for the domain, there's no need to log in before it will accept your email.
I don't think you understand the SMTP protocol. What I'm suggesting is that you don't connect to your own e-mail server and get that to relay the message - you do an mx lookup on the domain, and connect directly to the SMTP server that handles mail for the domain. That won't require credentials to allow inbound e-mail.
So you have to setup an SMTP account on their systems, and then configure your Email client to use that server to send that specific email?... no chance of anything going wrong with that then?
It would be good to know how they intend for this to work, if it's via your 'normal' SMTP route then there's no guarantee that the email will even have TLS outbound from that server, so it could just be a plain text email... actually it wouldn't be good at all, the entire idea is completely insane and insecure.
Let's not forget the social engineering risk.
Bob's heard of cash via email, so he knows it's real and not necessarily a scam. Why, Alice got some cash via Square yesterday and was telling Bob all about it. Come to think of it, Bob's antics almost always involve Alice, funny that, Bob wondered.
So anyhow, Bob sees this email from Triangle that he's got new funds but needs to run SecureTriangleRegistration.exe in order to secure the transfer to keep his money safe. Bob, believing what he wants to believe and buoyed by Alice getting cash yesterday, runs the attachment.
Oh nos!! :( Bob's computer has been pwned.
You don't really need to go that far.
Assume that HM.Gov(e) has got everyone (ish) on line.
How many people are there who have everything set to log in on start-up? 'Oh, it's so much easier, I can't remember all (or the single one) my passwords.
Unscrupulous agency carer (or builder or anyone else like a family member) finds a spare 30 seconds to send an email.
>You don't really need to go that far.
I'll grant you that, although I was trying to illustrate as well that you don't need to be registered with Square for this service for it decrease the security of others.
These two statements don't mix well:
"Email can be faked. Be careful and don't trust email if in doubt."
"You can now safely send and receive money via email."
Recently I placed an order through the Apple online store. After having placed it, I realised that I'd prefer to use a different credit card for payment. This was not achievable through the web interface, so I called the telephone number. The person at the other end of the telephone indicated that she could not alter the details within that order immediately herself, but that if I were to email her the new credit card details then she could pass them through to the correct department and have the payment details for this order amended. I was incredulous, and pointed out that this meant sending my payment information in plain text over the internet, and was thus completely insecure. She didn't seem to understand this at all, and added that this was how they had done it in the past. Needless to say, I simply cancelled the order and made a new one. It is extremely disappointing that a tech-savvy company allows such dangerous incompetence in its customer service. How may the masses be educated if the big corporations allow (condone, suggest!) this sort of idiotic behaviour.
"You seem to be forgetting that NOONE that has any sort of technical nous would be caught dead working on a Helldesk."
Not any more anyway -- I did helldesk for BT broadband until it all went from logic-based to screen prompt based and then to a far distant part of the old Empire.
We were told not to look and analise test returns but use the overall pass/fail message.
We could tell where a fault was on a cable, what type of fault, if there was a fault, the best way to fix it, etc.
Even to the point of clearly seeing it was not an exchange or customer issue but a line fault - but, rather that send an engineer out (costs money) best to send the job round the houses by following screen prompts.
They could never admit that the whole system was built around showing process had been followed (no matter if it was bollocks) rather than actually customer focused.
Eventually I took the money rather than follow the 'stress' route and go postal at work.
"We were told not to look and analise test returns but use the overall pass/fail message."
That explains a great deal. I spent a month trying to get Zen & BT to acknowledge that the authentication was failing with the correct credentials *intermittently* (were the down time could range from 1 hour to a week), and they kept taking me through 15 mins worth of check list to establish that the line was OK... Sigh. I took my business elsewhere.
Because we have Faster Payments where you can send and receive money between proper bank accounts at no cost and it only takes a minute or two for the transaction to go through. I've used Faster Payments to transfer money for bills to housemates, receive birthday presents from my parents, and pay bills for tradespeople.
Why would we need Square when our proper banking system has a decent system of money transfers?
Yep, I'm genuinely suprised it is needed at all.
I do look at this and all of the silly payment mechanisms that are advertised and ask myself - why can't I just do a bank transfer using my phone banking or online banking service? It uses decent two factor authentication to access the account, and there is a loop for any (new) transaction where you get an automated phone call to my mobile to confirm the transaction. Usually the payment is immediately in the recipient's account. I'm sure my bank probably isn't the best of the UK banks at security but it is certainly decent.
So (notwithstanding the hideous security) why would this system be needed? Is the US banking system that backward, in the land of the almighty dollar, that they can't do banking transactions through a clearing system (like BACStel, faster payments, etc)?
To do inter-bank cash transfers, you need to know the recipient's account number and sort code.
To set up a direct debit from an account, all you need to know is the account number and sort code - the account holder's name isn't checked. You can get up to all sorts of mischief, as Jeremy Clarkson found out. It will be be rectified eventually through the DD guarantee, but if they cleaned out your account to can be hassle until its fixed.
It really depends on how much you trust the payer, with friends and family it should be fine. With friends-of-friends maybe not.
And this is why I would *love* it if banks (especially on Business Bank accounts) gave you two account numbers - one for in-bound payments and one for outbound (okay, the outbound one will probably also need to allow inbound payments in case of bounced payments/refunds). If they could allow you to allocate X inbound/outbound ones for different purposes, it'll be brilliant.
Kinda wondering what the USP is over and above paypal (apart from insecurity), the transactions are near instant and the only delay is getting the transfer to your bank account done. Since I would presume most *sane* people would only use these kind of services for relatively small amounts the overhead of having a paypal account as a slush fund is pretty minimal.
Mr Clarkson discovered that some miscreant can set up a direct debit to a charity for a laugh (or to prove a point), but it was really a party trick on behalf of the prankster and nothing more.
The actual opportunities for actual fraud are fairly low. Any old Joe Bloggs can't set himself up to collect direct debits. Maybe he could set up one from your account to pay his gas bill or something - but that would be traceable to the beneficiary's gas account and would presumably result in fraud charges.
People used to give away their sort code and account number on every cheque they wrote - which could have been read by anyone involved in processing bill payments, balancing supermarket tills, or whatever. But still, direct debit fraud isn't incredibly common.
Certainly, I'd rather give someone my bank details than set up a system where I can be billed just because Square got cc'd on an email purporting to come from me.
Direct debit fraud happens. Described here at the BBC, it sounds like I'd use your bank details to buy something on direct debit. It can be done electronically with no validation.
http://www.bbc.co.uk/news/business-24085200
or search for ("Moneybox", "direct debit") - Moneybox is the BBC radio show about personal finance. Listen and worry.
You can stop bad direct debits if you identify them on your bank statement. Apparently you can't stop them from being set up.
As an SMS is sent to the payee every time money is deducted, they've plenty of time to dispute a payment during the 1-2 business days it takes to process.
Surely this should be payer and not the payee as the person being paid would presumably know whether the money had landed in the bank or not while the person having money withdrawn might not be aware of it in the event of a fraudulent withdrawal without the notification. Of course, going out of pocket for more than two days might now open customers up to automated fraud. Be careful what you post on Facebook, about an upcoming camping trip.
Oh Dear!
Now we have confused the transport mechanism with the security model.
Everything the article says and implies about SMTP security may be true, but what IS true is that a person's e-mail address may be as unique as their mobile number. If this is the case, then it can indeed be used as a to ken key to their bank account sort and account number. Of course, an e-mail address is more open and accessible in the public domain than a mobile number, but the required security may have to be introduced at the KYC point, in this case, as usual, the bank or account holder's issuer.
This conversation probably leads to one about LIABILITY, about which I have strong and controversial views, published elsewhere.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
