Visar inlägg med etikett aes. Visa alla inlägg
Visar inlägg med etikett aes. Visa alla inlägg

fredag 28 maj 2010

Hur spara applikationslösenorden?

En evig fråga för systemutvecklare och driftansvariga är – hur sparar vi lösenorden som applikationen behöver? Det är ofta flera lösenord som har med applikationen eller applikationsservern att göra. Lösenord till databasen, lösenord till certifikat, lösenord till keystores, lösenord för maskin till maskin-koppel och så vidare.

Alternativen som står till buds
Det finns följande enkla men osäkra alternativ:
  • Lösenord i klartext i konfigurationsfil
  • Lösenord i klartext i koden
Sen har vi de bra mycket säkrare men också jobbigare alternativen:
  • Krypterade lösenord i konfigurationsfil med nyckel i koden (kan vara en masternyckel för hela applikationen)
  • Krypterade lösenord i kod eller kodnära konfigurationsfil och lösenord i driftnära konfigurationsfil (känns lite bakvänt men ibland har man större förtroende för driftansvarig än för utvecklarna, t ex vid outsourcing)
  • Krypterade lösenord i en LDAP eller liknande
Och så har vi hybriden:
  • Krypterade lösenord i konfigurationsfil med delad nyckel – halva i koden, halva i konfigurationsfil.
Till sist har vi de väldigt säkra och grymt jobbiga alternativen:
  • Lösenord i huvudet på driftansvariga (anges vid varje driftsättning medelst många svordomar)
  • Drakonisk hårdvarulösning
Standardlösningar?
Mig veterligen så finns ingen standardlösning på det här i vaniljsmaken på Java EE. Istället så bestämmer varje team sig för hur man ska göra med lösenorden. Synd.

I lakritsjava (=enterprise) så finns det färdiga lösningar. IBMs WebSphere kör tyvärr default med en naiv XOR (ref):

"WebSphere Application Server stores passwords XOR encoded in the XML configuration files."

Men man kan plugga in valfri krypteringslösning genom att implementera deras CustomPasswordEncryption-interface eller sätta customPasswordEncryptionClass och customPasswordEncryptionEnabled i PropFilePasswordEncoder.bat/sh. Bra grejer.

i .NET-världen kanske det ser annorlunda ut, inte minst tack vare integrationen med Windows API:er som Data Protection API (CryptProtectData). Men jag är ingen klippa på .NET. Någon som kan hjälpa till? Kristofer?

Vad ska man brygga om man brygger hemma?
OK, men för oss som inte har betalat för en WebSphere-licens, vad står till buds? En XOR-kryptering med statisk nyckel i koden kanske?

Nja, så här säger min kollega Lars Johansson om XOR-kryptering:

XOR ger visserligen "perfekt sekretess" (bevisat av Shannon 1949), men det förutsätter följande:
  1. Nyckeln måsta vara lika lång som klartextmeddelandet.
  2. Nyckeln måste vara fullständigt slumpmässig. Så fort en nyckel återanvänds går det att knäcka kryptotexten!
Båda dessa ovanstående krav gör att perfekt sekretess med XOR inte går att realisera i praktiken. Använd en etablerad kryptoalgoritm i stället, t.ex. AES. Då är det inte lika noga med nyckellängden (256 bitar duger gott). Nyckeln bör dock fortfarande ha bra slump/entropi.

Vi borde skärpa oss lite
Jag tror de flesta tycker det här är för jobbigt och har alla maskinlösenord i klartext eller med defaultskydd. Vi borde skärpa oss lite. AES-kryptering med nyckeln i källkoden borde vara ett minimum. Gärna genom en snygg öppen källkodslösning som alla kan planka :).

Vad tycker ni andra? Hur gör ni?