Om man krypterar en sträng med t.ex. MD5-kryptering, kan man då vara säker på att kontrollsumman som algoritmen producerar är unik?

Jag håller på med en databas (i Access) där man skall lagra "anonyma" uppgifter om individer i ett åtgärdsprogram. Den som skall mata in uppgifterna vill dock ha ett sätt att veta om dom uppdaterar en befintlig individ eller registrerar en ny. Den som registrerar uppgifterna vet individens personnummer men det får bl.a. av anonymitetsskäl inte registreras i databasen.
Min tanke var då att köra en 1-vägskryptering av personnumret och lagra kontrollsumman i databasen.

Finns det någon algoritm som passar bättre till ändamålet?

Har inget bra bevis för det, men jag har läst att MD5 ska ge en unik kontrollsumma för ganska långa strängar (längre än ett personnummer iaf).

Problemet med din lösning är att uppgifterna inte blir anonyma på detta sätt. Visst, man ser inte vid första anblicken vem uppgifterna tillhör, men det är inga problem att ta reda på. Känner man till att personnumret är hashat med MD5 (vilket borde vara enkelt att ta reda på) kan man själv hasha ett personnummer man vill ha fram uppgifterna om. Har man uppgifter man vill vet vem det tillhör får man göra en "brute force" och testa alla tänkbara personnummer tills man får en träff.

Så, du kan alltså inte ha en sådan kontroll utan att uppgifterna blir spårbara.

/Johan

Visst... fast jag vet inte hur jag annars skall göra eftersom dom vill kunna hålla rätt på om individen redan är registrerad...

Tanken är att det inte på något sätt kommer att synas att det är personnumret dom skriver in... så ingen "oinvigd" kommer att veta att personID't är personnumret (eller en kombination av personnummer och något annat)...

Nej, hela poängen med en hash är att det finns kollisioner. Du har absolut inga garantier för unika värden.

Det känns som att ni tänker lite fel. Om ni ska garantera att folk inte kan registrera sig två gånger så måste ni lagra information som definitivt är unik per person. Och är den unik, så kan man alltid ta reda på vems personliga data som är lagrad, givet att man vet algoritmen (och det ska man alltid anta att folk gör).

Det ni vill uppnå är alltså en logisk omöjlighet, ni försöker göra "security by obfuscation", en ohållbar lösning.

<b>Nej, hela poängen med en hash är att det finns kollisioner. Du har absolut inga garantier för unika värden.</b>
Det var det jag misstänkte...

<b>Det känns som att ni tänker lite fel. Om ni ska garantera att folk inte kan registrera sig två gånger så måste ni lagra information som definitivt är unik per person.</b>
Ja, det är alltså inte "folk som registrerar sig två gånger", utan en handläggare som registrerar uppgifter om en individ i aktuellt åtgärdsprogram...

Jag känner mig i ett moment22 läge just nu...
Dom vill ha koll på om en individ har några uppgifter registrerade, t ex har deltagit i åtgärdsprogrammet vid ett tidigare tillfälle och efter ett avbrott (jobb, studier eller vad det än må vara) kommer tillbaka till åtgärdsprogrammet... men jag får inte lagra några personuppgifter i databasen.
Dom sa att dom kunde ha en lista på papper i en pärm över ID och individer... men dels tycker jag det inte låter smart ur säkerhetssynpunkt och sen låter det ganska omständigt. Låser man in pärmen i ett säkerhetsskåp så måste ju varje handläggare hämta pärmen före varje registreringstillfälle osv...

Om det är ok kan du alltid spara vilka personer som finns registrerade utan att koppla det till uppgifterna. Men då kan du givetvis aldrig uppdatera gamla uppgifter som du skrev i första inlägget.

/Johan

<b>>Ja, det är alltså inte "folk som registrerar sig två gånger", utan en handläggare som registrerar uppgifter om en individ i aktuellt åtgärdsprogram...</b>
Ok, poängen kvarstår ändå. Man kan inte se till att en specifik uppgift bara kommer in en gång, utan att också ha något som unikt identifierar den. Och har man det så kan man alltid få fram den specifika uppgiften, givet att uppgifterna är enkla att få fram.

En variant som hade funkat hade varit att ha med betydligt mer information än bara personnumret; även namn, t.ex. Problemet där är ju felstavningar, namnbyten, etc. (och att ni kanske inte får namnet?). Det kommer däremot bli betydligt säkrare.

Försök istället få till en ordentligt säker server, kryptera själva databasen och använd en stark nyckel. Eller är det dessutom juridiska problem? Typ integritet och så?
En lösning då skulle ju vara att räkna ut hashvärden med flera olika metoder. Sannolikheten att alla skulle ge samma svar för två olika input blir då extermt liten.

Johan: precis... moment22...

Tror jag använder min idé om kryptering i alla fall... ska kolla om det godkänns av beställaren.

Kön och födelseår skall lagras i databasen, så ifall två kontrollsummor (baserade på personnumret) skulle vara identiska kan man ju jämföra med dom variablarna med...

----

Niklas: Såg inte ditt svar innan jag postade...

Jepp... det är "juridiska problem" med... Beställaren är kommunens socialtjänst...
Servrarna är säkra, databasen kommer att vara skyddad osv... inga problem med det.


----
Hur som helst, tack för hjälpen båda två. =)

Det är ju rätt poänglöst att lagra beräknade data som man någorlunda enkelt kan "backtrace:a" till vad de från början beskrev. Det blir en rent visuell historia, folk som går in och tittar rakt i databasen kan inte se andra uppgifter direkt.

Men det räcker ju att ha ett lager emellan så kan man aldrig se någon annans uppgifter om man inte aktivt kollar efter det. Och kollar man aktivt efter det så kan man ändå ganska lätt ta reda på det...

Det är som att säga "Personnummer tänker vi inte lagra. Du får skriva in dem baklänges istället."

Hur gör man när man "backtrace:ar" en MD5-kontrollsumma? Har du något exempel på det?
Det lät intressant... har aldrig hört talas om hur man gör det...

Eftersom det är känt hur kontrollsumman beräknas kan man ta ett personnummer, vilket som helst, beräkna MD5-summan av det och se om man får en träff. Detta gör man sedan med alla tänkbara personnummer och till slut hittar man rätt.

/Johan

Hur vet man att det är ett personnummer?

I mitt fall kan det ju eventuellt vara endast personnumret... men ser det ut så här: "yyyymmdd-xxxx" eller "yymmdd-xxxx" eller "yyyymmddxxxx", etc..?

Det skulle ju kunna se ut så här också "<en text/kod som bara handläggaren känner till>yyyymm<samma text>ddxx<samma text igen>xx"

Hur kan man backtrace:a detta? Brute force skulle ta en evinnerlig tid... har ni något exempel på något annat?

...och sen för att återkoppla till vad min ursprungliga fråga:
Eftersom inte en MD5 summa är unik, hur kan man då vara säker på att den MD5-summa man har fått fram (genom att gissa vad invärdet var) betyder att invärdet är korrekt?

Principen bakom allt sånt är att en hacker har tillgång till algoritmen (annars blir det som sagt "security by obfuscation"). Men även om hackern inte har tillgång till den är det hyfsat enkelt i många fall: Ta ett enkelt personnummer, kolla vad det blir. Gör sen alla hash-algoritmer man kommer på och se om någon matchar. Om ingen matchar: Gör olika typer av modifikationer för att se om någon stämmer överens.

Det skulle vara den sista varianten som skulle hålla i så fall, eller i kombination med andra, längre coh inte fullt så strikta texter (så som namn etc.)

Brute force på bara personnummer tar inte speciellt lång tid. Man kan ju ha 100 * 12 * 31 * 1000 = 37,2 miljoner olika, alla andra är definitivt fel. (kontrollsumman gör att det bara blir 1000, istället för 10000).

Det går också att räkna ut hashen extremt fort eftersom det är en så kort text; skulle gissa på 100 i sekunden i genomsnitt ~ 2 dygn per personnummer. Så: Om man vill komma åt det är det inget större problem.

Min fråga kvarstår: Hur backtrace:ar man en MD5 summa skapat av ett värde som man inte känner till?

Säg att min dll skapar en MD5 summa av två invärden som är personnummer samt ett kodord som bara handläggaren känner till (eller något "hårdkodat" i dll-en).
Exempel:
<info>
Handläggaren skriver in personnumret på personen : 19860101-1234

Handläggaren skriver in kodordet: jag går och fiskar

Detta skickas till funktionen myMD5hash(str1,str2)

Funktionen returnerar en MD5-summa (exempel på invärde "19jag går och fiskar8601jag går och fiskarjag går och fiskar01jag går och fiskar123jag går och fiskar4jag går och fiskar")

Denna summa sparas i databasen.
</info>
Med brute force borde det ju då bli n^89 (där 89 är antalet skrivbara tecken i svenskt ASCII och n är antalet tecken, något som en hacker endast kan gissa sig till)...

För att du ska kunna göra på det viset måste du antingen använda samma "kodord" överallt, då är det lätt att lista ut (genom brute force eller t.ex. att en handläggare som känner till ordet avslöjar det för angriparen). Om du ska ha unika kodord måste du ha en lista med varje personnummers kodord och du är tillbaka på ruta ett...

Du måste tänka på att angriparen mycket väl kan känna till "dina trix", antingen genom att komma åt koden som skapar summan eller genom att någon handläggare "läcker" information.

/Johan

<b>genom brute force eller t.ex. att en handläggare som känner till ordet avslöjar det för angriparen</b>

Som jag nämnde, brute force borde ta en evinnerlig tid... (n^89 kombinationer där angriparen inte vet värdet på n) ...och eftersom en MD5-summa inte är unik så är det inte säkert att ens brute force skulle funka.

Vad gäller kodordet... dels så förutsätter ju alla system (vilket än det må vara) att användarna inte avslöjar kodord/lösenord och sen i detta fall så arbetar handläggarna under tystnadsplikt med känsliga uppgifter... så det borde inte vara några problem. "Hårdkodar" jag kodordet i dll:en så behöver ju inte ens handläggaren veta det...

Njaee... alltså... Så här:

1. Standardprincipen för en hash är att du utifrån en stor mängd (säg M stycken) data (med säg N bitar) genererar en mindre mängd data (säg n bitar, där n << N).
2. För att det ska vara en kryptografiskt stark hash ska ungefär hälften av alla bitar ändras när en bit ändras i input.
3. Du kommer totalt få 2^n olika möjliga hashar. För att det inte ska uppstå krockar ska ju M << 2^n.

Att detta kan användas i olika sammanhang är för att vi utgår från ett mycket stort N (en längre text, till exempel). Det krävs ungefär 2^(n-1) försök innan vi hittar en möjlig input som ger rätt output, något som i allmänhet är ganska stort, men vi kan inte ens säga att det är rätt, på grund av att det finns N^2 olika möjlighter.

Men i ditt fall är det inte riktigt samma situation. Du har betydigt mindre mängd möjliga input, och det är alltså bara de man behöver kolla på. Brute force _tar_ inte evinnerlig tid, på grund av det relativt låga antalet input. Sen finns det brister i MD5 som går att utnyttja också.

Din variant med kodord skulle kunna fungera, men enbart om användaren själv skriver i det varje gång.

Annars finns det flera metoder; dels att hacka sig in i koden, dels att bara använda sig av ditt program för själva hackingen.

Använd kryptering istället för hashing om det är det du är efter (för det är du ska ha om du vill att användaren ska skriva in lösenord varje gång). Men då kan du istället kryptera hela databasen.

Så det du menar är att de ej behöver ha tillgång till källkoden till dll:en för att lista ut hur jag har byggt upp invärdet till MD5-krypteringen, dom behöver inte veta att personID är ett personnummer och hur det är uppbyggt(Finns århundrade?, bindestreck?, kontrollsiffra?) och att dom inte behöver veta längden av kodordet?

<b>Sen finns det brister i MD5 som går att utnyttja också</b>
Ett alternativ är ju SHA, tex SHA-256... sägs vara säkrare?? Och jag läste någonstans att dom skall ge unika kontrollsummor. Kan det stämma?

<b>>Så det du menar är att de ej behöver ha tillgång till källkoden till dll:en för att lista ut hur jag har byggt upp invärdet till MD5-krypteringen, dom behöver inte veta att personID är ett personnummer och hur det är uppbyggt(Finns århundrade?, bindestreck?, kontrollsiffra?) och att dom inte behöver veta längden av kodordet?</b>
Det jag menar är att en hacker som är beslutsam definitivt kan komma över såna hinder. Tänk så här:
1. För att två personnummer ska betraktas som lika måste de matas in som input på samma sätt till MD5:en.
2. Det finns två sätt att garantera det; antingen så tvingar du användaren att alltid skriva på samma sätt, eller så låter du din applikation fixa det. Om användaren alltid måste skriva på ett sätt har du ett problem i att hon måste komma ihåg detta, information måste ges till nya användare etc. Det är mycket mänskliga faktorn som kan ställa till det. Om applikationen alltid sköter det kan en hacker antingen gå via din applikation, eller dekompilera din kod, för att se hur det är gjort.
3. Om du väljer att låta användaren hålla reda på mönster och kodord etc. så motsvarar det att ha ett lösenord. Och då är det betydligt enklare både för dig och för användare att ha en databas krypterad med en säker nyckel.
4. Om det är enkla grejer som bindestreck etc., så är det en smärre försening bara. När en hacker inser att det inte är straight-forward, provar den bara en radda andra. Det är bara kodord som verkligen kan ställa till det.

<b>>Ett alternativ är ju SHA, tex SHA-256... sägs vara säkrare?? Och jag läste någonstans att dom skall ge unika kontrollsummor. Kan det stämma?</b>
SHA är betydligt säkrare just nu, om jag inte minns fel, ja. Unika kontrollsummor kan den inte ge, men om den ger 256 bitars hash så är inte det något större problem. Du har så få möjliga input att det inte spelar någon roll vad gäller kollisioner.

Mina råd (återigen):
1. Lagra det som rena personnummer, se till att du har en riktigt hård kryptering på hela databasen istället.

eller

2. Lagra ett eller ett par olika hashar av personnumret (enbart för att andra användare i systemet inte ska kunna se dem direkt), men kör med personnumret som det är (tvinga åtminstone inte användaren att komma ihåg något vad gäller personnummer), och se till att du har en riktigt hård kryptering på databasen.