[PHP] Opslaan van API secrets in MySQL database

[Wolf3D]

Een tijd geleden ben ik begonnen met een webtool voor het handelen met cryptocurrencies op basis van een zelf ingestelde strategie. Hiervoor gebruik ik Bitvavo en hun API om automatisch orders te plaatsen of bepaalde informatie op te vragen.

Om dat te mogen/kunnen kan bij Bitvavo de mogelijkheid om deze API te gebruiken worden ingesteld, en daarbij krijg je een API-key en API-secret.

Mijn vraag gaat over deze API-secret. Om een API-call naar Bitvavo te doen heb ik deze secret steeds nodig, dus ik moet hem in mijn eigen database opslaan. Echter wat is de beste manier om dit op te slaan?
Ik kan hem natuurlijk encrypten, maar ik zal hem altijd weer moeten decrypten zodat ik de originele secret weer heb. Dat is natuurlijk beter dan plain text opslaan, maar echt veilig is dat ook niet.

Het enige wat ik zelf kon bedenken is een script dat op een andere server draait die ook weer als soort API werkt en waarmee ik API-secrets kan opvragen bij een user ID. In dat geval zijn de secrets in ieder geval gescheiden van de API-keys. Maar of dit nou echt beter/veiliger is, vraag ik me af.

Heeft iemand andere ideeën?

[Kalentum]

Om een API-call naar Bitvavo te doen heb ik deze secret steeds nodig, dus ik moet hem in mijn eigen database opslaan.

Dat hoeft natuurlijk niet, je kan het ook in een bestand (.env) opslaan en zorgen dat dat bestand niet in je versiebeheer terecht komt.

Is het alleen voor jezelf?

[watercoolertje]

Wolf3D schreef op vrijdag 28 mei 2021 @ 11:40:
Mijn vraag gaat over deze API-secret. Om een API-call naar Bitvavo te doen heb ik deze secret steeds nodig, dus ik moet hem in mijn eigen database opslaan. Echter wat is de beste manier om dit op te slaan?
Ik kan hem natuurlijk encrypten, maar ik zal hem altijd weer moeten decrypten zodat ik de originele secret weer heb. Dat is natuurlijk beter dan plain text opslaan, maar echt veilig is dat ook niet.

Ik sla ze zelf wel encrypted op, heb je alleen mijn database (encypted) of alleen mijn code (encryptie-key) kan je niks, heb je ze beide kan je pas decrypten.

Ik heb meerdere accounts die ik dynamisch kan toevoegen dmv webinterface dat werkt niet met een .env, die is vrij statisch en arrays kan je niet echt lekker kwijt in een .env.

Ik draai het wel lokaal op een raspberry dus ik maak me sws weinig zorgen dat er iets uit lekt je kan er van buiten al niet bij.

Het enige wat ik zelf kon bedenken is een script dat op een andere server draait die ook weer als soort API werkt en waarmee ik API-secrets kan opvragen bij een user ID. In dat geval zijn de secrets in ieder geval gescheiden van de API-keys. Maar of dit nou echt beter/veiliger is, vraag ik me af.

En waar sla je de token/secret voor die API dan op? Juist ook in de env of database

Let ook op bij het aanmaken dat je bij sommige exchanges rechten kan instellen, als je er alleen mee kan handelen kan niemand echt wat zinnigs mee, tenzij je een miljoen aan bitcoins hebt dan kunnen ze daar misschiennog de koers een beetje mee sturen

[ Voor 22% gewijzigd door watercoolertje op 28-05-2021 11:53 ]

[n9iels]

Het opslaan van secret en API keys is in zijn algeheel een vrij lastige opgave, simpelweg omdat je in je code op bepaald punt de echte key nodig hebt. Over het algemeen zie je dat secrets in een .env bestand (environment variables) worden gezet en tijdens runtime worden uitgelezen.

Opslaan in een database als plain text zou ik zelf afraden. Stel dat je ooit te maken krijgt met een datalek waarbij de volledige database naar buiten komt heb je een groot probleem. Echter is het altijd relatief... want als iemand jou FTP gegevens achterhaald kunnen ze ook weer dat mooie .env bestand downloaden. Een middenweg zou zijn: encrypted opslaan in je database en in de code, in een .env file, de decrypt key. Zo spreid je de risico's.

[Wolf3D]

Kalentum schreef op vrijdag 28 mei 2021 @ 11:46:
[...]


Dat hoeft natuurlijk niet, je kan het ook in een bestand (.env) opslaan en zorgen dat dat bestand niet in je versiebeheer terecht komt.

Is het alleen voor jezelf?

Bedoel je hiermee de https://www.php.net/manua...variables.environment.php ?
Het is nu nog alleen voor mezelf, maar in de toekomst kunnen anderen er ook gebruik van maken. Vandaar dat ik dit eerst goed geregeld wil hebben dan.

watercoolertje schreef op vrijdag 28 mei 2021 @ 11:49:
[...]
Ik sla ze zelf wel encrypted op, heb je alleen mijn database of alleen mijn code kan je niks, heb je ze beide kan je alles.

[...]
En waar sla je de token/secret voor die API dan op? Juist ook in de env of database

Maar als je bij de code kan, dan is toegang tot de database daarna niet veel moeilijker....

Haha, ja klopt, alleen dan moet je wel op twee plekken inbreken om API key en secret bij elkaar te krijgen...

[Wolf3D]

n9iels schreef op vrijdag 28 mei 2021 @ 11:51:
Het opslaan van secret en API keys is in zijn algeheel een vrij lastige opgave, simpelweg omdat je in je code op bepaald punt de echte key nodig hebt. Over het algemeen zie je dat secrets in een .env bestand (environment variables) worden gezet en tijdens runtime worden uitgelezen.

Opslaan in een database als plain text zou ik zelf afraden. Stel dat je ooit te maken krijgt met een datalek waarbij de volledige database naar buiten komt heb je een groot probleem. Echter is het altijd relatief... want als iemand jou FTP gegevens achterhaald kunnen ze ook weer dat mooie .env bestand downloaden. Een middenweg zou zijn: encrypted opslaan in je database en in de code, in een .env file, de decrypt key. Zo spreid je de risico's.

Oké, dus ook de environment variabelen, zoals @Kalentum ook al schreef. Kende ik zelf nog niet op die manier voor eigen gebruik, dus daar ga ik even induiken! Thanks!

[watercoolertje]

Wolf3D schreef op vrijdag 28 mei 2021 @ 11:54:
[...]
Bedoel je hiermee de https://www.php.net/manua...variables.environment.php ?
Het is nu nog alleen voor mezelf, maar in de toekomst kunnen anderen er ook gebruik van maken. Vandaar dat ik dit eerst goed geregeld wil hebben dan.

Daar heb ik nooit mee gewerkt, ik gebruik laravel en die slaat standaard de encryptiekey op in een .env file, misschien is dat op de achtergrond wel wat jij nu linkt maar daar heb ik nooitverder naar gekeken

Maar als je bij de code kan, dan is toegang tot de database daarna niet veel moeilijker....

Klopt, maar toch een extra drempel.

Haha, ja klopt, alleen dan moet je wel op twee plekken inbreken om API key en secret bij elkaar te krijgen...

Nou nee want op server 1 heb je toch iets staan waardoor je op server 2 dingen kan opvragen, dus dat is een beetje zelfde verhaal als de database, als je er eenmaal op zit kan je eigenlijk overal wel bij komen.

Daarnaast kan die hacker ook gewoon het bestand waar je met de API van bitvavo communiceert vlak voor de daadwerkelijke communicatie de key toch gewoon echoen of mailen of exporteren.

[Wolf3D]

@watercoolertje Klopt inderdaad, elke drempel is beter dan niets.
En inderdaad, kan je sowieso bij de informatie van server twee, alleen moet je daar iets meer moeite voor doen om alle informatie op te halen. Maar het gedoe weegt niet op tegen een meerwaarde in veiligheid denk ik ook inderdaad.

Je schreef eerder ook dat er rechten ingesteld kunnen worden bij sommige exchanges. Dat is bij Bitvavo inderdaad ook het geval. Je kan eigenlijk vooral informatie ophalen, en orders plaatsen mits er genoeg budget op Bitvavo staat, of crypto verkopen. Rechten op geld te verplaatsen of crypto naar andere wallets te verhuizen krijg je (gelukkig) niet. Dus het risico is ook vrij beperkt gelukkig ....

[ Voor 6% gewijzigd door Wolf3D op 28-05-2021 12:08 ]

[Kalentum]

Wolf3D schreef op vrijdag 28 mei 2021 @ 11:54:
[...]


Bedoel je hiermee de https://www.php.net/manua...variables.environment.php ?
Het is nu nog alleen voor mezelf, maar in de toekomst kunnen anderen er ook gebruik van maken. Vandaar dat ik dit eerst goed geregeld wil hebben dan.

Ja dat maar ik zou ook iets gebruiken zoals dit https://github.com/vlucas/phpdotenv

Dat PHPDotEnv is exact bedoeld om jou probleem op te lossen.

[ Voor 6% gewijzigd door Kalentum op 28-05-2021 12:12 ]

[Wolf3D]

@Kalentum Oké thanks! Waarschijnlijk een nog beter alternatief is een combinatie van dit: https://deliciousbrains.c...ds/#secret-key-encryption met daarbij de master key opgeslagen in een environment variabele. Dan hoef ik niet een hele library te hebben om steeds gegevens weg te schrijven en op te halen, maar hoef ik de key maar 1x in een environment variabele op te slaan.

[Hydra]

Het maakt natuurlijk helemaal niks uit of je master key in een env var staat of de API key. Da's alleen maar extra complexiteit en geen extra veiligheid.

Het is in ieder geval heel gangbaar om dit soort keys bij deployment mee te geven als env vars. Die komen dan zelf meestal tijdens deployment uit een tool als Vault, maar de meeste CI/CD systemen hebben hier ook opties voor. Je hoeft pas moeilijk te doen met libraries e.d. als je at runtime secrets moet kunnen wisselen zonder een redeployment.

[Wolf3D]

Het ding is dat ik voor elke gebruiker de API-secret moet opslaan. Dus dan moet ik al een combinatie UID met API-secret opslaan en ophalen. Is het niet netter om dan alleen één key in de env var op te slaan en die te gebruiken om de secrets in de database te versleutelen?

[Hydra]

Wolf3D schreef op vrijdag 28 mei 2021 @ 13:38:
Het ding is dat ik voor elke gebruiker de API-secret moet opslaan.

Was handig geweest dat even duidelijk te maken.

Dan ja; dan is een aparte encryption key gebruiken wel een goed idee.

[Ben(V)]

Als iedere gebruiker een eigen api secret heeft is het dan niet handiger dat die gebruiker dat zelf bewaart en ingeeft als het nodig is?

[Hydra]

Ben(V) schreef op maandag 31 mei 2021 @ 15:31:
Als iedere gebruiker een eigen api secret heeft is het dan niet handiger dat die gebruiker dat zelf bewaart en ingeeft als het nodig is?

Zie je een niet technische gebruiker dit al doen?

Ik vermoed dat 't gaat om OAuth keys die uitgegeven worden als je bijvoorbeeld Facebook logins wil supporten.

[Wolf3D]

Belangrijker nog: Het is een automatisch trading systeem. Dus ik heb op elke moment toegang nodig en kan niet steeds de gebruiker om zijn API-secret vragen.

Een voorbeeld is Cryptohopper, waarbij je ook gebruik kan maken van de API van Bitvavo. Zie https://support.bitvavo.c...maken-en-koppelen-bitvavo
Je vult ook daar de API-key en secret in bij Cryptohopper (in dit geval). En cryptohopper zal dus ook deze gegevens opslaan, hopelijk ook op een veilige manier :-)

[ThomasG]

Wolf3D schreef op maandag 31 mei 2021 @ 16:13:
Belangrijker nog: Het is een automatisch trading systeem. Dus ik heb op elke moment toegang nodig en kan niet steeds de gebruiker om zijn API-secret vragen.

Een voorbeeld is Cryptohopper, waarbij je ook gebruik kan maken van de API van Bitvavo. Zie https://support.bitvavo.c...maken-en-koppelen-bitvavo
Je vult ook daar de API-key en secret in bij Cryptohopper (in dit geval). En cryptohopper zal dus ook deze gegevens opslaan, hopelijk ook op een veilige manier :-)

In dat geval kun je er niet omheen om de API key (en secret) op te slaan. Het beste wat je kunt doen is zorgen dat deze versleuteld in de database staan, zodat het nog enigszins veilig is als er bijvoorbeeld onverhoopt een database backup uitlekt.

Wat ik zie bij Bitvavo is dat zij de API key aan één of meerdere IP adresen kunnen locken (whitelist). Je zou jouw gebruikers dus kunnen vertellen dit in te stellen, en welk IP adres ze daar kunnen invoeren. Mochten de API key en secret uitlekken, dan kunnen ze er niet zoveel veel; tenzij de gebruiker het niet goed heeft ingesteld op Bitvavo. Of iemand heeft toegang tot jouw server, maar dan heb je natuurlijk een veel groter probleem.

[Wolf3D]

ThomasG schreef op maandag 31 mei 2021 @ 16:54:
[...]
Wat ik zie bij Bitvavo is dat zij de API key aan één of meerdere IP adresen kunnen locken (whitelist). Je zou jouw gebruikers dus kunnen vertellen dit in te stellen, en welk IP adres ze daar kunnen invoeren. Mochten de API key en secret uitlekken, dan kunnen ze er niet zoveel veel; tenzij de gebruiker het niet goed heeft ingesteld op Bitvavo. Of iemand heeft toegang tot jouw server, maar dan heb je natuurlijk een veel groter probleem.

Je zou zeggen inderdaad dat dat een prima extra beveiliging is, ware het niet dat dit totaal niet werkt. Helaas!
Zodra ik het IP-adres invul heb ik geen toegang meer. Laat ik hem leeg, dan werkt het. Helaas reageert Bitvavo hier niet op, maar ook vond ik bij de Bitvavo documentatie met betrekking tot Cryptohopper (https://support.bitvavo.c...maken-en-koppelen-bitvavo) bij stap 3 puntje 2, dat ook daar werd aangegeven dat het IP-adres leeggelaten moet worden.
Erg vreemde zaak.

[CH4OS]

watercoolertje schreef op vrijdag 28 mei 2021 @ 11:49:
Ik heb meerdere accounts die ik dynamisch kan toevoegen dmv webinterface dat werkt niet met een .env, die is vrij statisch en arrays kan je niet echt lekker kwijt in een .env.

Waarom zou je een array in een .env kwijt willen? Daar is de .env namelijk niet voor bedoeld. In de loop van tijd kan die array immers ook wijzigen, dus eigenlijk wil je alleen key => value opslaan in een .env, dan ben je ook het meest flexibel.
Als alternatief zou je dan eventueel Redis kunnen gebruiken, die doet basicly hetzelfde, immers.

En waar sla je de token/secret voor die API dan op? Juist ook in de env of database

In het verleden sloeg ik dat voor een webapplicatie op in een database, maar tegenwoordig zou ik daar .env voor gebruiken.
De database gebruik ik tegenwoordig veel meer/eerder om dynamische data op te slaan, een API key wijzigt niet zo heel snel, maar als het wijzigt, moet het wel makkelijk kunnen, dat kan met een .env dan eigenlijk het simpelst en er is geen extra afhankelijkheid; elk systeem kan een tekstbestand wel lezen.

[CH4OS]

Hydra schreef op maandag 31 mei 2021 @ 16:04:
Zie je een niet technische gebruiker dit al doen?

Zie je een niet-technische gebruiker überhaupt een API instellen? Je kan er dus wel redelijkerwijs van uit gaan dat die persoon technisch genoeg is en dus weet wat 'ie doet. Op zich is het dus ook geen rare vraag.

[ Voor 3% gewijzigd door CH4OS op 01-06-2021 11:18 ]

[Hydra]

CH4OS schreef op dinsdag 1 juni 2021 @ 11:17:
[...]
Zie je een niet-technische gebruiker überhaupt een API instellen?

Lekker selectief gequote!

[CH4OS]

Hydra schreef op dinsdag 1 juni 2021 @ 11:24:
Lekker selectief gequote!

Ik zie niet waarom ik jouw vermoeden erbij zou moeten citeren op jouw retorische vraag? Overigens maakt dat voor mijn vraag ook totaal niet uit, even los van dat gebruikers hun Oauth keys niet eens zullen weten normaliter gesproken.

[ Voor 23% gewijzigd door CH4OS op 01-06-2021 11:29 ]

[Hydra]

CH4OS schreef op dinsdag 1 juni 2021 @ 11:27:
[...]
Ik zie niet waarom ik jouw vermoeden erbij zou moeten citeren op jouw retorische vraag?

Omdat je op deze manier de context verwijdert. Natuurlijk gaan gebruikers waarschijnlij niet zelf API-keys copy pasten over het algemeen. Maar er zijn genoeg situates (zoals oauth flows) waarbij je gebruikers specifieke keys encrypted op moet slaan. Als jij iemand toestemming geeft je Bunq transacties te zien, wordt daar onderwater een key voor uitgewisseld. Deze wordt, als het goed is, encrypted opgeslagen.

De TS bevestigt nota bene dat dit het geval is.

Dus ik snap je reactie niet zo goed. Of je snapt dit en je begrijpt dat het geen zin heeft om zo te reageren, of je snapt niet waar ik het over hebt en dan is het meestal ook zinniger niet (op deze manier) te reageren.

[watercoolertje]

CH4OS schreef op dinsdag 1 juni 2021 @ 11:14:
[...]
Waarom zou je een array in een .env kwijt willen? Daar is de .env namelijk niet voor bedoeld. In de loop van tijd kan die array immers ook wijzigen, dus eigenlijk wil je alleen key => value opslaan in een .env, dan ben je ook het meest flexibel.

Er was de vraag of het niet in een .env kan en ik noem dus juist op dat dat niet handig is als je meerdere api's tegelijk wilt opslaan

De suggestie dat ik dat dus juist een goed idee vindt is dus erg raar, want die suggestie wek ik helemaal niet in tegendeel, we denken er hetzelfde over.

[ Voor 36% gewijzigd door watercoolertje op 01-06-2021 12:12 ]

[JustFogMaxi]

Hier gebruik je normaal secret stores voor, oa: https://www.vaultproject.io/ Voor jou misschien overkill.

[CH4OS]

Hydra schreef op dinsdag 1 juni 2021 @ 11:39:
Omdat je op deze manier de context verwijdert.

Dat vind ik dus wel meevallen. Maar let's agree to disagree.

Natuurlijk gaan gebruikers waarschijnlij niet zelf API-keys copy pasten over het algemeen. Maar er zijn genoeg situates (zoals oauth flows) waarbij je gebruikers specifieke keys encrypted op moet slaan.

True, maar die hoef je een gebruiker ook niet te laten invullen. Daar biedt de Oauth API ook genoeg endpoints voor, ervan uitgaande dat jouw vermoeden juist is.

Als jij iemand toestemming geeft je Bunq transacties te zien, wordt daar onderwater een key voor uitgewisseld. Deze wordt, als het goed is, encrypted opgeslagen.

De TS bevestigt nota bene dat dit het geval is.

Maar dat is niet de vraag die @Ben(V) stelde. Hij stelde de vraag of een gebruiker niet voor elke (page) request zijn key / secret met de hand kan invullen (als het niet teveel requests zijn bijvoorbeeld), dan hoef je het niet op te slaan. Wat je niet bewaard, kun je niet kwijt raken of buit gemaakt worden bij een inbraak.

In het geval van Oauth is dat inderdaad wat lastig, maar dan kun je inderdaad de API en secret keys ook op een andere manier ophalen (al dan niet met een refresh token). Maar dat is een aanname, zonder meer context erover vanuit @Wolf3D weten we het niet. En uitgaan van aannames kan nog wel eens vervelende fouten opleveren in de programmeer wereld, dus dat doe ik liever niet.

[Ben(V)]

Ik ken verder de context van de applicatie niet, maar is het niet een enorm security en afbreuk risico om al die api keys centraal op te slaan.
Stel je wordt gehackt dan is TS verantwoordelijk voor de schade.

[CH4OS]

Ben(V) schreef op dinsdag 1 juni 2021 @ 12:47:
Ik ken verder de context van de applicatie niet, maar is het niet een enorm security en afbreuk risico om al die api keys centraal op te slaan.
Stel je wordt gehackt dan is TS verantwoordelijk voor de schade.

Sums kunnen keys "gebind" worden aan bijvoorbeeld een IP-adres of sessie. Dan werkt die specifieke key (en secret) alleen wanneer via een bepaalde IP-adres (of vanuit een specifieke sessie) wordt verbonden.

[ Voor 4% gewijzigd door CH4OS op 01-06-2021 13:05 ]

[Hydra]

Ben(V) schreef op dinsdag 1 juni 2021 @ 12:47:
Ik ken verder de context van de applicatie niet, maar is het niet een enorm security en afbreuk risico om al die api keys centraal op te slaan.

Ja, vandaar ook dat je ze encrypted opslaat. Maar dan heb je zeker wel het issue dat als iemand de database EN de key weet te bemachtigen, je alsnog een issue hebt. Vandaar ook dat je zoveel gebruik moet maken voor tools die je hier bij helpen. Dus bijv. de secret manager van je cloud provider, en/of managed databases met encryption at rest.

[Hydra]

CH4OS schreef op dinsdag 1 juni 2021 @ 13:04:
[...]
Sums kunnen keys "gebind" worden aan bijvoorbeeld een IP-adres of sessie. Dan werkt die specifieke key (en secret) alleen wanneer via een bepaalde IP-adres (of vanuit een specifieke sessie) wordt verbonden.

Dat wordt tegenwoordig eigenlijk nooit meer gedaan simpelweg omdat dat niet gaat werken met cloud omgevingen waar je IP adressen constant wijzigingen. IPv4 is gewoon 'op'.

Als je af kunt stemmen met de 'andere kant' wordt meestal een beveiligde verbinding gebruikt (mutual TLS, VPN, etc.). Als je dit niet kan, dan rest je eigenlijk alleen het encrypten van de data at rest and je secret management verdomde serieus te nemen.

[CH4OS]

Hydra schreef op dinsdag 1 juni 2021 @ 14:59:
[...]


Dat wordt tegenwoordig eigenlijk nooit meer gedaan simpelweg omdat dat niet gaat werken met cloud omgevingen waar je IP adressen constant wijzigingen. IPv4 is gewoon 'op'.

Als je af kunt stemmen met de 'andere kant' wordt meestal een beveiligde verbinding gebruikt (mutual TLS, VPN, etc.). Als je dit niet kan, dan rest je eigenlijk alleen het encrypten van de data at rest and je secret management verdomde serieus te nemen.

Andere optie, wat je ook met 2FA-enabled apps en websites ziet, app passwords waaraan je de key en secret koppelt. Mogelijkheden te over, lijkt me. Je kunt die prima in een vault opslaan, zoals de reeds gelinkte https://www.vaultproject.io/. Mutual TLS heb ik geen ervaring mee, eens in verdiepen wat dat dan exact is.

EDIT: Ah, Mutual TLS is dus gewoon een authenticatie van beide kanten.

[ Voor 8% gewijzigd door CH4OS op 01-06-2021 15:37 ]