Open NtWriteCode opened 4 months ago
almet
commented
4 months ago Hi, thanks for opening this discussion. I understand how having bank accounts listed in ihatemoney could be useful, thanks for proposing it.
My main concern on this is related to security: these information can be useful for potential attackers, and would increase the interest of the data we have.
In practice, would that be a problem for other folks?
NtWriteCode
commented
4 months ago That's a nice thought!
I'd ask the following 2 questions:
a) Does stealing the Bank Account ID can lead to any security incidents or actual issues? In my point of view, no, because it's not associated with a specific user's password, so an attacker can't just try to log in the the password of user + freshly gathered account ID, since we don't even have user passwords - AFAIK.
On their own Account IDs are not enough to withdraw money or log into any account - at least in Europe, not sure about other parts of the world.
b) After a breach, can this data be used against the user for things like phishing, etc? YES, sure! But I think 90% of the features of this project can be used for phishing (in case of a breach) 😄
At least that's my 2cents. And of course it's not a necessary feature to use in case someone is concerned about leaks.
almet
commented
4 months ago Thanks for the follow-up questions.
a) Does stealing the Bank Account ID can lead to any security incidents or actual issues?
I believe it is, yes.
Collecting data on people in order to better impersonate them is called doxing. It is a thing for sure.
From the same wikipedia article:
Doxing may be carried out for reasons such as online shaming, extortion, and vigilante aid to law enforcement.
So, the question is not really if it is a thing, but how could we prevent it, and how should we make the people aware this exists. As it is right now, the current data contained in ihatemoney is not very sensitive, you have names, and of course you have the list of bills. It is indeed already something.
It seems totally possible to use this data to for instance setup a direct debit for a subscription service. It seems used in the wild, and as such it is also a thing.
So the question isn't really if this is a problem, I believe it is clear that it could be one, but how should we handle this.
I'm thinking about different ways this can be circumvented:
I'm curious about the inputs of other folks, especially @zorun, on the matter.
Glandos
commented
4 months ago Hi! (Long time, no see!)
It's not very clear for GDPR if IBAN is a personal identifying data, but this site says so: https://www2.deloitte.com/fr/fr/pages/risque-compliance-et-controle-interne/articles/livre-blanc-gdpr.html
I wasn't able to find any other valuable resources :(
ihatemony is currently storing 2 kind of informations:
Users are free to export and remove any data at any time, so there's no worry for this. However, as @almet said, data is not encrypted, so any data exfiltration can be an issue.
I would advise not to store those kind of informations. And if a PR starts to work on this, I would advise to make this feature disabled by default, and add a toggle in project preference, with a big fat warning.
NtWriteCode
commented
4 months ago Thanks for the follow-up questions.
a) Does stealing the Bank Account ID can lead to any security incidents or actual issues?
I believe it is, yes.
Doxing
Collecting data on people in order to better impersonate them is called doxing. It is a thing for sure.
From the same wikipedia article:
Doxing may be carried out for reasons such as online shaming, extortion, and vigilante aid to law enforcement.
You're correct and I agree that it's an extra "attack vector" that an attacker can use if the server gets pwned or the password gets leaked/bruted.
However... I know it's not a professional point of view, but I can't see how an IBAN (eg, a Revolut ID) can be used for shaming. If it's about being a link in a chain (so someone can link together maybe a shaming purchase with your ihatemoney details), that's correct. Still, practically everything can be a link between doxable items, especially PRIVATE purchases and "debts" you owe to your friends.
So, the question is not really if it is a thing, but how could we prevent it, and how should we make the people aware this exists. As it is right now, the current data contained in ihatemoney is not very sensitive, you have names, and of course you have the list of bills. It is indeed already something.
I disagree with this because ihatemoney lets you input anything to the bill and users can easily input sensitive data there. Not to mention using the full name as a nickname, which is also sensitive. One can even LINK full photos of bills too... Sensitive data can be there as well, eg. tax numbers etc.
Direct debit
It seems totally possible to use this data to for instance setup a direct debit for a subscription service. It seems used in the wild, and as such it is also a thing.
I only know my example, but isn't it common in the world (I honestly don't know) to use SMS or a Bank application to first approve the transaction? I thought it was the default. I know for sure I wouldn't be able to subscribe anywhere without 2FA. Also, I'm not even sure if you can SUBSCRIBE using IBAN. I thought that applies only to bank card.
Don't take my word for granted, but - at least in EU - I think it's a must for banks to use 2fa: https://www.termsfeed.com/blog/2-factor-auth-eu-payments/
Round 2 about direct debit. I'll just leave my previous message, but I just read about the topic and found this: http://news.bbc.co.uk/2/hi/7174760.stm I find it hard to believe, but still, a WTF if it happened... How can someone charge me money without me agreeing on it at least once (eg. by presenting a physical card [NFC] or inputting a pin or a 2fa device)? If that's a common thing and possible, that's like an explicit begging for bad guys to abuse. I feel like there MUST be something the article is not telling... (Or it's that terrible feature...)
eg. I just found this: https://en.wikipedia.org/wiki/Direct_debit Which says direct debit MUST be authorized first from the payee.
"A direct debit instruction must in all cases be supported by some sort of authorization for the payee to collect funds from the payer's account. There are generally two methods to set up the authorization:
1) One method involves only the payer and the payee, with the payer authorizing the payee to collect amounts due on his or her account
2) The other method requires the payer to instruct his or her bank to honour direct debit notes from the payee
So the question isn't really if this is a problem, I believe it is clear that it could be one, but how should we handle this.
I'm thinking about different ways this can be circumvented:
* Using cryptography: it's something we discussed in the past (see [Encrypt the data on the server side #524](https://github.com/spiral-project/ihatemoney/issues/524)) but never actually managed to do. It adds a layer of complexity and I'm not sure we want this (as you might know, we try to keep things as simple as they can be). * Adding warnings / explanations about this so the users are aware of the risk they take.
I understand that cryptography would improve security a littlebit, but I think there are 2 cases again:
a) Password gets leaked/brutforced/somehow-hacked Doesn't matter as data would still be decrypted, so encryption is worthless here.
b) Server gets hacked An attacker wouldn't be able to just simply query the database, which is a nice extra addition, I agree! But if someone targets you specifically, the attacker can just simply infect the local ihatemoney instance and add extra code to save the encryption password in case it's dynamic. If it's static, like a config value, then it's again worthless, since the attacker can read it exactly like ihatemoney.
Not to mention that the admin PW is stored in plaintext, so in case of a server attack, one can just simply use the admin password... (If it's enabled)
So, in my opinion, the case of protecting ihatemoney on a hacked server is bleeding from way too many wounds, but I do agree on the thing that encryption is not going to make things worse :)
* Not adding this feature, and privileging a broader "user comment" feature, which could be hacked to put the IBANs if that makes sense.
Adding a regular "user comment" could be a nice "bypass" around the problem, because this way ihatemoney won't advise people to put private things in there, however, the frontend could simply warn you explicitly NOT TO PUT anything private, because it's stored in an unsafe way on the server.
(Ps.: I do understand that implementing a comment feature instead is just a workaround and taking off liability from ihatemoney's shoulders)
NtWriteCode
commented
4 months ago I just read the issue about the encryption topic, and I agree with it.
Not sure if it's really like that, but I feel like ihatemoney and its own hosted version is a nice demo, but obviously I wouldn't put all my sensitive data in there. If it has a paid plan, that'd probably have encryption and more features, but then of course it's normal to expect such encryption...
As long as it's a self-hosted version, encryption isn't adding too much security if it adds anything at all.
It'd be really great if we could add bank account numbers or Revolut IDs or any similar things to users, so if someone wants to pay, it's easier to copy the ID from the "profile" and simply transfer the money :)
Just to clarify, I don't think any special new thing, like a new profile or similar. Instead an extra field is perfectly enough for the participant, where you can specify various Bank account related information that would also show up somehow on the UI.
So it's hopefully a small feature-ish with hardly any great impact, and also extremely useful :)
(Ps.: The software is really great, thank you very much for maintaining it! I'll do my part by translating it to my language)