IBAN opslaan in een database

[TheNephilim]

Niet doen! Dat hoor je meestal als je bankrekeningnummers op wil slaan. In dit geval gaat het om IBAN, al is het idee natuurlijk hetzelfde.

We maken verbinding doormiddel van https, maar is het een goed idee om de IBAN's nog encrypted in de database op te slaan, of is dat niet nodig? Op internet lees ik de wildste verhalen, al gaat dat vaak over creditcard nummers en dat ligt iets gevoeliger natuurlijk. Maar toch ben ik benieuwd wat je er nou praktisch gezien mee kunt doen. Bij encrypten kom je meteen op het probleem, dat je de key ook ergens op moet slaan.

Op de website is een formulier te vinden (voor ingelogde gebruikers), waar naast een factuuradres ook een IBAN en de naam van de rekeninghouder word weergegeven. Deze moeten aanpasbaar zijn, er is ook een check aanwezig om te zien of het ingevulde IBAN wel geldig is.

Encrypten, maar waar dan de sleutel opslaan? Of zijn er nog andere mogelijkheden?

[Barryvdh]

De key kan je opslaan op de server in de code (of config ofzo), en dan buiten je versiebeheer houden eventueel.
Als ze dan de datavase kraken, een dump vinden ergens of toegang verschaffen tot phpmyadmin krijgen ofzo, hebben ze iig de key nog niet. Als ze bij de bestanden kunnen, kunnen ze natuurlijk wel overal bij, maar dat is nu ook..

[matthijsln]

Gewoon normaal opslaan en je niet zo druk maken.

Uiteraard wel zorgen dat je security in je applicatie, hosting, systeembeheer, social engineering etc. op orde is.

[ Voor 3% gewijzigd door matthijsln op 26-06-2014 16:44 ]

[Morax]

TheNephilim schreef op donderdag 26 juni 2014 @ 16:25:
Niet doen! Dat hoor je meestal als je bankrekeningnummers op wil slaan. In dit geval gaat het om IBAN, al is het idee natuurlijk hetzelfde.

We maken verbinding doormiddel van https, maar is het een goed idee om de IBAN's nog encrypted in de database op te slaan, of is dat niet nodig? Op internet lees ik de wildste verhalen, al gaat dat vaak over creditcard nummers en dat ligt iets gevoeliger natuurlijk. Maar toch ben ik benieuwd wat je er nou praktisch gezien mee kunt doen. Bij encrypten kom je meteen op het probleem, dat je de key ook ergens op moet slaan.

Op de website is een formulier te vinden (voor ingelogde gebruikers), waar naast een factuuradres ook een IBAN en de naam van de rekeninghouder word weergegeven. Deze moeten aanpasbaar zijn, er is ook een check aanwezig om te zien of het ingevulde IBAN wel geldig is.

Encrypten, maar waar dan de sleutel opslaan? Of zijn er nog andere mogelijkheden?

Je kan er een incasso voor starten, die sinds SEPA wordt aangekondigd en achteraf eventueel gestorneerd kan worden. Daar houdt het ongeveer op.

Er zijn zat bedrijven die gewoon op hun website hun IBAN-nummer hebben staan, en heb nog nooit gehoord dat dat problemen opleverde.

Conclusie: gewoon plain text opslaan.

[TheNephilim]

Barryvdh schreef op donderdag 26 juni 2014 @ 16:42:
De key kan je opslaan op de server in de code (of config ofzo), en dan buiten je versiebeheer houden eventueel.
Als ze dan de datavase kraken, een dump vinden ergens of toegang verschaffen tot phpmyadmin krijgen ofzo, hebben ze iig de key nog niet. Als ze bij de bestanden kunnen, kunnen ze natuurlijk wel overal bij, maar dat is nu ook..

Ja precies, mocht dan je database gestolen worden, kun je in ieder geval zeggen dat de bankrekeningnummers versleuteld opgeslagen zijn.

matthijsln schreef op donderdag 26 juni 2014 @ 16:44:
Gewoon normaal opslaan en je niet zo druk maken.

Uiteraard wel zorgen dat je security in je applicatie, hosting, systeembeheer, social engineering etc. op orde is.

Maar dan heb je geen enkel valnet als (bijv.) de hoster slachtoffer word van hackers.

Morax schreef op donderdag 26 juni 2014 @ 16:49:
[...]


Je kan er een incasso voor starten, die sinds SEPA wordt aangekondigd en achteraf eventueel gestorneerd kan worden. Daar houdt het ongeveer op.

Er zijn zat bedrijven die gewoon op hun website hun IBAN-nummer hebben staan, en heb nog nooit gehoord dat dat problemen opleverde.

Conclusie: gewoon plain text opslaan.

Dat is waar, je kunt er niet meteen heel veel mee. Toch is het wel een stukje privacy ergens en zullen consumenten zeker 'schrikken' als hun bankrekeningnummers onversleuteld opgeslagen zijn en je bekend moet maken dat (hoe dan ook) de database op straat ligt.

---

Goed, zo kijk ik er even tegenaan. De kans dat alles op straat ligt is klein en dan zijn er meer problemen. Al zou je door het toch te versleutelen de boel niet meteen waterdicht hebben, dan heb je er in ieder geval wat aan gedaan.

[Merethil]

[b]TheNephilim schreef op donderdag 26 juni 2014 @ 17:23:
Dat is waar, je kunt er niet meteen heel veel mee. Toch is het wel een stukje privacy ergens en zullen consumenten zeker 'schrikken' als hun bankrekeningnummers onversleuteld opgeslagen zijn en je bekend moet maken dat (hoe dan ook) de database op straat ligt.

---

Goed, zo kijk ik er even tegenaan. De kans dat alles op straat ligt is klein en dan zijn er meer problemen. Al zou je door het toch te versleutelen de boel niet meteen waterdicht hebben, dan heb je er in ieder geval wat aan gedaan.

Vooral gezien IBAN niet echt iets is waar je echt wat mee kan behalve dus de al genoemde incasso's kan je deze casus natuurlijk doortrekken naar bijvoorbeeld adresgegevens; ik vind het vervelender wanneer mijn adresgegevens open en bloot op straat liggen dan m'n IBAN die ik toch al doorgeef bij elke verkoop die ik hier op Tweakers doe.

Gegevens die een persoon invult op jouw website zullen allemaal gevoelig zijn, behandel ze ook als zodanig. Dit hoeft niet te betekenen dat je alles moet hashen/encrypten: Zorg er gewoon voor dat de beveiliging zo goed mogelijk is en je bent al een heel stuk.
Paswoorden e.d. moeten natuurlijk altijd gehashed (liefst met salt natuurlijk) zijn, maar da's meer omdat je mensen wilt behoeden voor de fout van overal hetzelfde wachtwoord gebruiken.

Mocht je echt veel beveiligd willen hebben kan je de data altijd nog encrypten en dus de decryption-key buiten de database bewaren. Kost je echter ook weer performance; zal het een drukbezochte website/webapp worden?

[ Voor 7% gewijzigd door Merethil op 26-06-2014 18:08 ]

[Gomez12]

Morax schreef op donderdag 26 juni 2014 @ 16:49:
[...]
Je kan er een incasso voor starten, die sinds SEPA wordt aangekondigd en achteraf eventueel gestorneerd kan worden. Daar houdt het ongeveer op.

Er zijn zat bedrijven die gewoon op hun website hun IBAN-nummer hebben staan, en heb nog nooit gehoord dat dat problemen opleverde.

Conclusie: gewoon plain text opslaan.

Er zit echter wel een verschil tussen bedrijven en consumenten, bedrijven zijn vanwege tal van redenen vaak actiever met bank-saldo's bekijken dan particulieren.
En voor een stornering moet je toch binnen een maand zitten.

Als ik alleen al naar mezelf kijk, dan gaan mijn vaste lasten er vanaf zonder omkijken, dan gaat er nog een vast gedeelte naar rekening x, dan houd ik nog een bedrag over aan "speelgeld" en in mijn hoofd bereken ik grofweg bij elke aankoop hoeveel speelgeld ik nog heb, dan kan het zomaar gebeuren dat ik 2 maanden niet op inet bankieren kijk. Of vanwege een vakantie of ... of ...

Maar als je de IBAN wilt opslaan dan zou ik het in ieder geval optioneel maken en duidelijk vermelden dat je het doet (dan kunnen mensen als ik ervoor kiezen om niets te kopen of het vinkje uit te zetten ipv dat ik achteraf geconfronteerd wordt met allerlei narigheid).
De technische afhandeling is wmb niet zo interessant (de meeste wachtwoordbestanden etc zijn ook gekraakt, dus de techniek geeft je enkel maar tijd en geen zekerheid imho)

[ThomasG]

De kans dat de gebruiker gehackt wordt is groter dan dat de database gehackt wordt. Je kunt het beter optioneel maken, zodat de gebruiker kan kiezen of zijn/haar rekening nummer wordt opgeslagen bij hun account. Je zult het dan nog wel op de facturen oid. moeten hebben, maar omdat dat betaal informatie is kun je dat sowieso beter versleutelen.

Daarbij zou ik er voor kiezen om aan de kant van de gebruiker de laatste cijfers van het rekeningnummer als sterretjes te laten zien. En het weergeven en wijzigen van het nummer achter een soort geheime vraag. In de database zelf kun je het natuurlijk ook altijd AES-256 versleuteld opslaan, wat met persoonsgegevens sowieso al een goed idee is.

[naitsoezn]

TheNephilim schreef op donderdag 26 juni 2014 @ 16:25:
Op internet lees ik de wildste verhalen, al gaat dat vaak over creditcard nummers en dat ligt iets gevoeliger natuurlijk.

Waarom is dat natuurlijk? Wat kun je met een kaal creditcard-nummer méér dan je met een IBAN zou kunnen?

[MrMonkE]

Gewoon een rekeningnummer mensen. Die worden te hooi en te gras opgeslagen in combinatie met namen, Het is waarschijnlijk het meest opgeslagen stukje data in nederland.

[dev10]

naitsoezn schreef op donderdag 26 juni 2014 @ 20:11:
[...]

Waarom is dat natuurlijk? Wat kun je met een kaal creditcard-nummer méér dan je met een IBAN zou kunnen?

Op zich niet zo heel veel, maar als je je creditcardnummer invult op internet, vul je ook altijd je CVC en vervaldatum in. De combinatie van die drie kun je beduidend meer mee dan met enkel een los IBAN.

[Brainstorm]

Creditcard gegevens kunnen ook gebruikt worden bij identity theft, waarbij je uiteindelijk meerdere bronnen van informatie met elkaar combineert. Misschien dat dit hier ook speelt: je slaat het nummer op in combinatie met allerlei andere persoonsgegevens. En: encryptie van gevoelige data is uiteindelijk gewoon 1 beveiligingslaag, die gecombineerd met andere lagen (SSL, firewall, patches, etc) pas het uiteindelijke doel bereikt.

Overigens zijn er ook trucjes om je decryptiekey weer verder te beveiligen. Een bepaalde applicatie waar ik momenteel mee werk, slaat o.a. creditcard nummers op. De nummers zijn met public-private key encryptie in de database encrypted opgeslagen. De decryptie key staat in een file op disk op de servers die de nummers kunnen decrypten. Deze file is echter op zijn beurt ook weer encrypted, met een tweede key. Bij het starten van de webserver wordt de decryptiesleutel van de tweede key meegegeven. De webserver gebruikt deze key om de eerste uit de file te lezen, de eerste key wordt vervolgens decrypted in het geheugen opgeslagen. De tweede key wordt uit het geheugen verwijderd.
Het opstarten van de webserver (waarbij de tweede key meegegeven moet worden) kan alleen handmatig plaatsvinden door minimaal twee verschillende personen (dus 2 personen tegelijkertijd aanwezig) vanaf een bepaalde fysieke locatie. De webserver heeft nog extra beveiligingsmaatregelen om de keys te beschermen.

Wederom: laag op laag aan beveiliging, niet alleen tegen hackers, maar ook tegen aanvallen van binnenuit...

[The Eagle]

Los van welke manier van opslaan dan ook: je moet bij het opslaan van stamgegevens twee zaken onderscheiden. Zakelijke stamgegevens, en consumenten stamgegevens. Voor consumenten heb je te maken met privacywetgeving. Voor bedrijven niet; die zijn al openbaar middels de KvK opvragingen. Daar is ook geen privacywaakhond voor iirc.

[Morax]

Gomez12 schreef op donderdag 26 juni 2014 @ 19:52:
[...]

Er zit echter wel een verschil tussen bedrijven en consumenten, bedrijven zijn vanwege tal van redenen vaak actiever met bank-saldo's bekijken dan particulieren.
En voor een stornering moet je toch binnen een maand zitten.

Terugboeken kan tot 8 weken na de incassodatum

[EvilWhiteDragon]

Waarom wil je het opslaan? Om het koopproces voor de klant te vergemakkelijken, of omdat je zelf die informatie nodig hebt? Want als het alleen is om het de klant makkelijker te maken, kan je ook het wachtwoord van de klant gebruiken als encryptiesleutel, waarmee alleen de klant zelf het kan decrypten. Nadeel is wel dat als het wachtwoord gereset moet worden, de IBAN alsnog door de klant ingevuld moet worden.
Voor procesgegevens zoals facturatie kan je dit soort informaties tijdelijk encrypted met een vaste key opslaan, om de gevoelige informatie te verwijderen nadat de facturatie is afgehandeld.

[IceM]

TheNephilim schreef op donderdag 26 juni 2014 @ 16:25:
Niet doen! Dat hoor je meestal als je bankrekeningnummers op wil slaan. In dit geval gaat het om IBAN, al is het idee natuurlijk hetzelfde.

Kun je linken naar onderbouwing hiervan? Er is niets mis met het opslaan van een IBAN nummer wanneer je dit in jou systeem nodig hebt (voor automatische incasso's bijvoorbeeld). Het is misschien wel privacygevoelige informatie (net zoals NAW gegevens bijvoorbeeld) maar dat betekend niet dat het niet plain text opgeslagen mag worden in een database.

Moeilijk doen met encryptie is nergens voor nodig. Heb je het IBAN nummer nodig? Lekker opslaan in de database. Niet nodig? Dan niet opslaan.

[TheNephilim]

Merethil schreef op donderdag 26 juni 2014 @ 18:08:
[...]


Vooral gezien IBAN niet echt iets is waar je echt wat mee kan behalve dus de al genoemde incasso's kan je deze casus natuurlijk doortrekken naar bijvoorbeeld adresgegevens; ik vind het vervelender wanneer mijn adresgegevens open en bloot op straat liggen dan m'n IBAN die ik toch al doorgeef bij elke verkoop die ik hier op Tweakers doe.

Gegevens die een persoon invult op jouw website zullen allemaal gevoelig zijn, behandel ze ook als zodanig. Dit hoeft niet te betekenen dat je alles moet hashen/encrypten: Zorg er gewoon voor dat de beveiliging zo goed mogelijk is en je bent al een heel stuk.
Paswoorden e.d. moeten natuurlijk altijd gehashed (liefst met salt natuurlijk) zijn, maar da's meer omdat je mensen wilt behoeden voor de fout van overal hetzelfde wachtwoord gebruiken.

Mocht je echt veel beveiligd willen hebben kan je de data altijd nog encrypten en dus de decryption-key buiten de database bewaren. Kost je echter ook weer performance; zal het een drukbezochte website/webapp worden?

Nee dat is waar, IBAN zie je vaker openbaar terug, vooral bij bedrijven. Toch denk ik dat consumenten liever zien dat hun bankrekeningnummer 'veilig' opgeslagen word. De andere gegevens kunnen ook gevoelig zijn inderdaad, zeker als je kijkt naar social engineering.

De webservice word hopelijk goed bezocht, maar echt enorm veel acties kan een gebruiker niet uitvoeren. Ik zou persoonlijk misschien eens per maand gebruik maken van de service, dus het zou mee moeten vallen.

ThomasG schreef op donderdag 26 juni 2014 @ 20:03:
De kans dat de gebruiker gehackt wordt is groter dan dat de database gehackt wordt. Je kunt het beter optioneel maken, zodat de gebruiker kan kiezen of zijn/haar rekening nummer wordt opgeslagen bij hun account. Je zult het dan nog wel op de facturen oid. moeten hebben, maar omdat dat betaal informatie is kun je dat sowieso beter versleutelen.

Inderdaad, een gebruiker zelf gaat meestal minder goed met gegevens om en de kans dat de PC besmet is is ook best groot. Zeker een argument om niet te overdrijven qua maatregelen.

EvilWhiteDragon schreef op vrijdag 27 juni 2014 @ 08:59:
Waarom wil je het opslaan? Om het koopproces voor de klant te vergemakkelijken, of omdat je zelf die informatie nodig hebt? Want als het alleen is om het de klant makkelijker te maken, kan je ook het wachtwoord van de klant gebruiken als encryptiesleutel, waarmee alleen de klant zelf het kan decrypten. Nadeel is wel dat als het wachtwoord gereset moet worden, de IBAN alsnog door de klant ingevuld moet worden.
Voor procesgegevens zoals facturatie kan je dit soort informaties tijdelijk encrypted met een vaste key opslaan, om de gevoelige informatie te verwijderen nadat de facturatie is afgehandeld.

Gebruikers nemen een abonnement af en de beheerders regelen zelf facturen en betalingen en dergelijke. Ze willen alles met machtigingen doen, wel handmatig, maar de gegevens moeten uit de webservice komen.

IceM schreef op vrijdag 27 juni 2014 @ 10:21:
[...]


Kun je linken naar onderbouwing hiervan? Er is niets mis met het opslaan van een IBAN nummer wanneer je dit in jou systeem nodig hebt (voor automatische incasso's bijvoorbeeld). Het is misschien wel privacygevoelige informatie (net zoals NAW gegevens bijvoorbeeld) maar dat betekend niet dat het niet plain text opgeslagen mag worden in een database.

Moeilijk doen met encryptie is nergens voor nodig. Heb je het IBAN nummer nodig? Lekker opslaan in de database. Niet nodig? Dan niet opslaan.

Nee, dat kan ik niet. Meer een 'populaire' schreeuw die je op Stackoverflow ziet en dergelijke, als men begint over gevoellige info opslaan. Ik had verwacht dat hier ook wel te horen

---

Goed, genoeg argumenten en suggesties dus! Hiermee kan ik zeker een beslissing maken in overleg met de klant. In eerste instantie gaan we eerst maar eens in kaart brengen welke gegevens dan nog meer versleuteld zouden moeten worden, als we er toch al mee aan de slag gaan.

Een andere mogelijkheid is om het niet te doen, maar dat hangt ook van de klant af.