ClockTools-blog

Ontwikkelaarstools

Hoe lang moet een API-sleutel zijn?

Gebruik ten minste 128 bits onvoorspelbare willekeur voor een opake API-sleutel; 256 bits is een goede standaardkeuze. De codering bepaalt het aantal zichtbare tekens.

Door , ontwikkelaar en uitgever | | Beoordeeld volgens het redactionele beleid van ClockTools

Veilige API-sleutel weergegeven door lichtgevende willekeurige blokken van 128 tot 256 bits
Inhoudsopgave

Gebruik minimaal 128 bits onvoorspelbare willekeur voor een nieuwe opake API-sleutel; 256 willekeurige bits is een goede standaardkeuze als het ontvangende systeem dit accepteert. Dat betekent niet dat elke sleutel 256 tekens lang moet zijn. Dezelfde 256-bitswaarde wordt weergegeven als 64 hexadecimale tekens, 43 Base64URL-tekens zonder opvulling, 44 Base64-tekens met opvulling of 52 Base32-tekens zonder opvulling.

Gebruik de ClockTools API-sleutelgenerator om eerst de gewenste entropie te kiezen en daarna het formaat. Het hulpmiddel berekent het benodigde aantal bytes en tekens voordat het iets genereert. Zo kunt u binnen een veldlimiet blijven zonder zichtbare lengte met veiligheid te verwarren.

ClockTools API Key Generator ingesteld op een 256-bits Base64URL-sleutel met 43 tekens en 32 willekeurige bytes
ClockTools API Key Generator ingesteld op een 256-bits Base64URL-sleutel met 43 tekens en 32 willekeurige bytes

Wat is de juiste API-sleutellengte?

Er bestaat geen universeel aantal tekens, omdat een teken geen vaste hoeveelheid beveiliging vertegenwoordigt. Een hexadecimaal teken bevat 4 bits. Een uniform willekeurig Base64URL-teken bevat bijna 6 bits, behalve in de laatste gedeeltelijke groep. Een decimaal cijfer bevat ongeveer 3,32 bits. Het alfabet, de generatiemethode en het aantal onafhankelijke keuzes bepalen de zoekruimte.

Voor praktische planning kunt u hier beginnen:

Gewenste entropieHexBase64URL, zonder opvullingGebruikelijke toepassing
128 bits / 16 bytes32 tekens22 tekensHoge weerstand tegen brute force bij uniforme generatie en goede bescherming
256 bits / 32 bytes64 tekens43 tekensRuime standaardkeuze voor nieuwe opake API-sleutels en tokens

De Python secrets-documentatie noemt 32 bytes, of 256 bits, voldoende voor de gebruikelijke toepassingen van die module. De documentatie waarschuwt ook dat de benodigde hoeveelheid willekeur verandert met de rekenkracht en de dreiging. Dat maakt 256 bits een verstandige standaardkeuze, geen magische regel die naleving garandeert.

De dienst die het toegangsgegeven accepteert, bepaalt nog steeds het vereiste formaat. Als een bestaande API 32 hexadecimale tekens, een vast voorvoegsel of een door de provider uitgegeven token voorschrijft, houd u dan aan die specificatie. Verleng, verkort of hercodeer een providersleutel niet ongemerkt.

Waarom verschillen entropie en het aantal tekens?

Entropie beantwoordt een relevantere vraag dan het uiterlijk: hoeveel even waarschijnlijke geheime waarden had de generator kunnen produceren? Een uniform willekeurige 128-bitswaarde heeft 2^128 mogelijkheden. Een 256-bitswaarde heeft 2^256 mogelijkheden. Meer zichtbare tekens helpen alleen als die tekens onafhankelijke, onvoorspelbare keuzes toevoegen.

RFC 4086 laat zien waarom dit onderscheid belangrijk is. Een lange uitvoer uit een kleine of voorspelbare beginwaarde kan veel minder echte informatie bevatten dan de lengte doet vermoeden. Een waarde die eruitziet als 128 bits, maar uit slechts een 8-bitsbeginwaarde is gegenereerd, biedt bijvoorbeeld nog steeds maar 256 mogelijke beginwaarden. Lengte maakt zwakke willekeur niet goed.

Daarom zijn Math.random(), tijdstempels, opeenvolgende ID's, gebruikersnamen of aaneengeschakelde apparaatgegevens geen geschikte basis voor API-geheimen. MDN beschrijft crypto.getRandomValues() als de browsermethode voor cryptografisch sterke willekeurige waarden. ClockTools vereist die API en valt niet terug op Math.random().

Voor tekenalfabetten is de theoretische berekening:

entropy bits = character count × log2(number of distinct characters)

Bij een alfabet van 62 letters en cijfers zijn 22 onafhankelijke tekens nodig om boven 128 bits uit te komen en 43 om boven 256 bits uit te komen. Met alleen cijfers zijn respectievelijk 39 en 78 tekens nodig. Een kleiner alfabet is niet automatisch zwak; er zijn alleen meer tekens nodig om dezelfde entropie te bereiken.

Hoe lang is een 256-bits API-sleutel in elke codering?

Codering verandert de weergave, niet de onderliggende willekeurige bytes. Het livehulpmiddel van ClockTools en de bijbehorende regressietests gebruiken 32 willekeurige bytes voor een doel van 256 bits. Die bytes worden als volgt weergegeven:

CoderingTekenset en opvullingAantal tekens uit 32 bytes
Hexadecimaal0–9, a–f64
Base64URLURL-veilig alfabet, opvulling verwijderd43
Base64Standaardalfabet met =-opvulling44
Base32A–Z, 2–7, opvulling verwijderd52
Dezelfde 256 willekeurige bits weergegeven als 64 hex-, 43 Base64URL-, 44 Base64- en 52 Base32-tekens
Dezelfde 256 willekeurige bits weergegeven als 64 hex-, 43 Base64URL-, 44 Base64- en 52 Base32-tekens

De aantallen volgen de coderingsregels in RFC 4648. Hexadecimaal is het gemakkelijkst te controleren en wordt breed geaccepteerd, maar vraagt twee tekens per byte. Base64URL is compacter en vermijdt de tekens + en /, die lastig kunnen zijn in URL's en bestandsnamen. Gewone Base64 kan die tekens bevatten en gebruikt opvulling. Base32 wordt in veel workflows zonder onderscheid tussen hoofdletters en kleine letters verwerkt, maar is langer.

Kies een formaat dat de ontvangende applicatie betrouwbaar kan parseren. Verwijder opvulling alleen als het protocol dat toestaat. Ga er niet vanuit dat een URL-veilig alfabet betekent dat u de waarde veilig in een URL kunt opnemen. API-geheimen kunnen lekken via browsergeschiedenis, verwijzingsgegevens, reverseproxylogboeken en analyses.

Wanneer is 128 bits genoeg?

Een uniform willekeurige opake geheime waarde van 128 bits biedt een enorme zoekruimte voor online raadpogingen. In veel systemen maken verzoeklimieten, monitoring, isolatie van toegangsgegevens en de moeilijkheid om pogingen te testen een uitputtende zoekactie onpraktisch. Een willekeurige waarde van 256 bits biedt een grotere marge en kost weinig bij de meeste nieuwe server-sideontwerpen.

Baseer de keuze wel op een dreigingsmodel en de systeemspecificatie. Overweeg 256 bits als u het formaat van de toegangsgegevens bepaalt, de opslagkosten verwaarloosbaar zijn en de sleutel waardevolle of langdurige toegang beschermt. Een goed gegenereerde 128-bitssleutel kan passend zijn als een protocol de grootte vastlegt, het toegangsgegeven kort geldig is of een bestaand veld niet meer tekens kan bevatten.

Meer bits compenseren een openbaar geworden geheime waarde niet. Een 256-bitssleutel die in een openbare repository is vastgelegd, kan direct worden gekopieerd; niemand hoeft die met brute force te achterhalen. Trek een mogelijk gelekte sleutel in of roteer die, in plaats van hem alleen door een langere tekenreeks te vervangen.

Maakt een voorvoegsel een API-sleutel sterker?

Nee, niet als het voorvoegsel vast of voorspelbaar is. Tekst zoals live_, test_ of sk_ kan mensen en scanners voor geheime waarden helpen een toegangsgegeven te herkennen, maar voegt geen entropie toe. Een willekeurige waarde van 256 bits blijft 256 willekeurige bits, ongeacht of de zichtbare vorm met vijf bekende tekens begint of zonder zulke tekens.

Voorvoegsels kunnen wel nuttig zijn. Ze kunnen productiesleutels van testmateriaal onderscheiden, aangeven tot welke familie een toegangsgegeven behoort en de kans verkleinen dat een sleutel in het verkeerde systeem wordt geplakt. Houd dat doel gescheiden van de sterkte van de authenticatie.

Dezelfde waarschuwing geldt voor achtervoegsels en openbare sleutel-ID's. Een openbare identificatie kan het juiste databaserecord vinden zonder de geheime waarde prijs te geven, maar mag niet worden geaccepteerd als bewijs van autorisatie. ClockTools telt vaste voor- en achtervoegsels en openbare ID's niet mee in het totaal aan willekeurige bits.

Wat doet er nog meer toe behalve de lengte?

De lengte kiezen hoort alleen bij het aanmaken. De OWASP-richtlijnen voor geheimenbeheer behandelen geheime waarden gedurende hun hele levenscyclus: aanmaken, roteren, intrekken en verlopen. De API-sleutelrichtlijnen van Google Cloud benadrukken ook beperkingen, isolatie, monitoring, het vermijden van blootstelling in clientcode en rotatie.

Checklist voor API-sleutels: willekeur, weergave en beheer gedurende de levenscyclus
Checklist voor API-sleutels: willekeur, weergave en beheer gedurende de levenscyclus

Controleer alle drie de lagen voordat u een productiesleutel uitgeeft:

  1. Willekeur: genereer minimaal 128 onvoorspelbare bits met een cryptografisch veilige bron; geef voor een nieuwe opake sleutel de voorkeur aan 256 bits als het systeem die accepteert.
  2. Weergave: kies een codering die de ontvanger accepteert; tel alleen het willekeurige deel, geen vast voorvoegsel of scheidingsteken.
  3. Levenscyclus: beperk de rechten, verstuur de sleutel via HTTPS, sla hem op in een secrets manager, voorkom logregistratie in platte tekst, monitor het gebruik, leg waar passend een vervaldatum vast en zorg voor snelle intrekking.

API-sleutels zijn in veel ontwerpen toegangsgegevens die werken op basis van bezit: wie de waarde heeft, kan de bijbehorende bevoegdheden gebruiken. Ze zijn doorgaans geschikter om een aanroepende applicatie of een project te identificeren dan om een menselijke gebruiker te authenticeren. Combineer of vervang ze voor gevoelige gebruikersacties met een authenticatie- en autorisatiemethode die daarvoor is ontworpen.

Hoe kunt u de sleutel veilig genereren?

Om snel een waarde lokaal in de browser te genereren, opent u de API-sleutelgenerator, laat u de gewenste entropie op 256 bits staan en kiest u het vereiste formaat. De standaardinstelling Base64URL genereert 32 willekeurige bytes die als 43 tekens worden weergegeven. Generatie en exportvoorbereiding vinden lokaal in de browser plaats. De pagina houdt geheime waarden bewust buiten gedeelde instellingen.

Genereer voor productie-infrastructuur zo mogelijk binnen de vertrouwde omgeving waarin de geheime waarde wordt opgeslagen. Node.js crypto.randomBytes, Python secrets of OpenSSL kunnen overdracht via het klembord voorkomen. De ClockTools-pagina toont opdrachten voor die omgevingen zonder een gegenereerde sleutel op te nemen.

Registreer de gegenereerde waarde bij de applicatie die deze gaat verifiëren. Een willekeurige tekenreeks wordt niet vanzelf een werkend toegangsgegeven omdat hij eruitziet als een API-sleutel. Rechten, geldigheidsduur, intrekking en verificatie van verzoeken horen bij het ontvangende systeem. De ClockTools-methodologie voor API-sleutels legt de browserbron, rejection sampling, geteste lengtes en beperkingen uit. De GUID-generator is beschikbaar voor identificatoren die geen gedeelde geheimen zijn.

Veelgestelde vragen

Is een API-sleutel van 32 tekens veilig?

Het hangt af van het alfabet en de generatiemethode. Tweeëndertig willekeurige hexadecimale tekens bevatten 128 bits, terwijl 32 uniform willekeurige letters en cijfers ongeveer 191 bits bevatten. Een voorspelbare tekenreeks van 32 tekens kan nog steeds zwak zijn.

Hoeveel tekens bevat een 256-bits API-sleutel?

De sleutel bestaat uit 64 hexadecimale tekens, 43 Base64URL-tekens zonder opvulling, 44 Base64-tekens met opvulling of 52 Base32-tekens zonder opvulling. Dit zijn verschillende weergaven van dezelfde 32 willekeurige bytes.

Is 128 bits genoeg voor een API-sleutel?

Een uniform willekeurige opake geheime waarde van 128 bits biedt een zeer grote zoekruimte voor raadpogingen en kan geschikt zijn als het protocol of de veldgrootte dat vereist. Voor nieuwe ontwerpen is 256 bits een ruime standaardkeuze als compatibiliteit en opslag dit toelaten.

Maakt een langere API-sleutel een API altijd veiliger?

Nee. Lengte verhelpt geen voorspelbare generatie, te ruime rechten, onveilige opslag, blootstelling in clientcode, logregistratie in platte tekst of het ontbreken van intrekking. Die maatregelen moet u afzonderlijk ontwerpen.

Moet een API-sleutel een voorvoegsel bevatten?

Een vast voorvoegsel kan het sleuteltype of de omgeving aanduiden en scanners voor geheime waarden helpen, maar voegt geen entropie toe. Tel bij het beoordelen van de sterkte alleen het onvoorspelbare deel.

Is Base64URL sterker dan hexadecimaal?

Nee. Bij dezelfde willekeurige bytes bevatten beide dezelfde entropie. Base64URL is alleen compacter, terwijl hexadecimaal vaak gemakkelijker te controleren is en breed wordt ondersteund.

Over de auteur

Vigneshwaran Vijayakumar

Oprichter, ontwikkelaar en uitgever van ClockTools | Digital Marketing Manager | India

Vigneshwaran is een ingenieur met tientallen jaren technische ervaring, waaronder professioneel werk als Digital Marketing Manager in Dubai. Zijn werk verbindt data-analyse, zoekmachineoptimalisatie, conversie-optimalisatie, contentsystemen, visuele productie en toegepaste AI en machine learning. Bij ClockTools zet hij die multidisciplinaire ervaring om in gerichte browserhulpprogramma's en praktische, bronbewuste handleidingen.

LinkedIn-profiel