---

Hej

Jeg står i en situation hvor nogle brugere lagre følsomme data hos mig.
Brugerne anvender noget specielt software som kryptere og gemmer deres data
hos mig.

Som det fungere idag har jeg en database med brugernes konto-informationer i
klartekst liggende på en CD i en kommode. Denne konstellation er jeg ikke
særlig tryg ved og vil egentlig helst slippe af med den. Jeg havde derfor
påtænkt at hashe samtlige kodeord så ingen længere kan se dem, hverken
utilsigtet eller tilsigtet. Kodeordene kan dog stadig fint bruges da
softwaren så bare anvender de hashede koder.

Men hvad gør jeg hvis en kundes hus brænder ned. Kundens PC bliver til aske
sammen med sedlen han har liggende i en skuffe med hans konto-oplysninger.
Han kan naturligvis ikke huske det obskure kodeord i hovedet og jeg kan
ingen steder se kodeordet i klartekst. Ergo kan han nu ikke hente hans data
fra mig igen da de jo er krypteret med det kodeord der forsvandt i
flammerne...

Som jeg ser det er der tale om valget mellem pest eller kolera:

1) Ansvaret ligger hos mig: Jeg opbevarer kodeordet i klartekst. Får jeg
indbrud står jeg potentielt med mine ædlere dele i postkassen.

2) Ansvaret ligger hos brugeren selv: Jeg opbevarer ingen koder i klartekst.
Eneste sted hvor koden står i klartekst er på den seddel som brugeren har
med sine konto-oplysninger. Men hvor brugbar er en remote backupløsning hvis
kunden ikke kan genskabe ens data hvis kundens virksomhed brænder ned?

Der er den tredje mulighed som lidt er et kompromis med sikkerheden:
3) Ansvaret ligger hos mig: Jeg kryptere kodeordene og har mulighed for at
dekryptere kodeordene igen ved brug af en "master-kode". Problemet ligger i
at med flere ansatte der skal administrere systemet bliver dette systemet
måske endnu mere usikkert end mulighed 1.

Nogle gode råd eller ideer til hvordan jeg bør forholde mig til dette
problem?

På forhånd tak!

--
MVH
Thomas Eg Jørgensen
*Get in, Sit down, shut up and hang on!*

---

On 2005-02-05, Thomas Eg Jørgensen <tejo03@kom.auc.dk> wrote:
> Nogle gode råd eller ideer til hvordan jeg bør forholde mig til dette
> problem?

Lad kunden vaelge en god adgangskode, han kan huske (noget i stil med
``einsteinblevfoedtfor100aarsiden''), og lad ham opbevare en seddel med
adgangskoden i en bankboks (eller flere), hvor han kan hente den, hvis
han skulle glemme den.

Hvis dataene er saa vigtige, som de lyder, maa udgiften til en eller
flere bankbokse vaere acceptabel.

I oevrigt kan du jo blot lave en aftale med kunden om, at de kan betale
dig for at paatage sig ansvaret. Saa er det op til kunden at vurdere,
hvor meget beskyttelse, han har behov for, og det vil saa fremgaa ud fra
kravene i jeres kontrakt.

Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen wrote:
> Hvis dataene er saa vigtige, som de lyder, maa udgiften til en eller
> flere bankbokse vaere acceptabel.

Det virker oplagt...men vær' opmærksom på:

1) De er mulige at bryde ind i.

2) Banken dækker ikke nødvendigvis et tab.

http://www.forbrugerraadet.dk/presse/alle/presse021/


Udgiften til en bankboksen ligger mellem 125 - 500 kr årligt.




http://www.saksager.dk/product.asp?product=1034&page=1 :)

---

Thomas Eg Jørgensen wrote:
> Jeg står i en situation hvor nogle brugere lagre følsomme data hos mig.
> Brugerne anvender noget specielt software som kryptere og gemmer deres data
> hos mig.

Jeg synes jeg mangler lidt information for at kunne saette mig bedre ind
i situationen. Det lader til, at du og disse brugere er ansat hos samme
arbejdsgiver og at du fungerer som en del af IT afdelingen eller
tilsvarende. Er det korrekt?

Er det i brugernes eller arbejdsgiverens/dataejerens interesse at deres
data er tilgaengelige for autoriserede brugere og utilgaengelige for
uautoriserede ditto?

(Svaret paa ovenstaaende afgoer ca. hvem der skal have
hovedpinen/ansvaret for at opbevare en klartekst udgave af oplysningerne.)

> Som det fungere idag har jeg en database med brugernes konto-informationer i
> klartekst liggende på en CD i en kommode.
[..]

Med "konto-informationer" menes der saa brugernavn og tilhoerende
adgangskoder?

Bankbokse koster ikke ret meget i aarlig leje. Ville det vaere
acceptabelt at hver bruger gemmer deres oplysinger i en bank og i
noedstilfaelde skal vente til naeste bankdag med at kunne tilgaa sine
krypterede oplysninger igen?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

"Thomas Eg Jørgensen" <tejo03@kom.auc.dk> skrev i en meddelelse
news:cu3fnu$24vf$1@news.cybercity.dk...
> Hej
>
> Jeg står i en situation hvor nogle brugere lagre følsomme data hos mig.
> Brugerne anvender noget specielt software som kryptere og gemmer deres
data
> hos mig.
>
> Som det fungere idag har jeg en database med brugernes konto-informationer
i
> klartekst liggende på en CD i en kommode. Denne konstellation er jeg ikke
> særlig tryg ved og vil egentlig helst slippe af med den. Jeg havde derfor
> påtænkt at hashe samtlige kodeord så ingen længere kan se dem, hverken
> utilsigtet eller tilsigtet. Kodeordene kan dog stadig fint bruges da
> softwaren så bare anvender de hashede koder.

Da du tilsyneladende stoler på din kryptering kan du vel lægge denne
database på din backup-server.
Så skal du bare bruge din egen adgangskode.

> Men hvad gør jeg hvis en kundes hus brænder ned. Kundens PC bliver til
aske
> sammen med sedlen han har liggende i en skuffe med hans konto-oplysninger.
> Han kan naturligvis ikke huske det obskure kodeord i hovedet og jeg kan
> ingen steder se kodeordet i klartekst. Ergo kan han nu ikke hente hans
data
> fra mig igen da de jo er krypteret med det kodeord der forsvandt i
> flammerne...

Hvis man har dit kodeord har man koden i klartekst.

> Som jeg ser det er der tale om valget mellem pest eller kolera:
>
> 1) Ansvaret ligger hos mig: Jeg opbevarer kodeordet i klartekst. Får jeg
> indbrud står jeg potentielt med mine ædlere dele i postkassen.
>
> 2) Ansvaret ligger hos brugeren selv: Jeg opbevarer ingen koder i
klartekst.
> Eneste sted hvor koden står i klartekst er på den seddel som brugeren har
> med sine konto-oplysninger. Men hvor brugbar er en remote backupløsning
hvis
> kunden ikke kan genskabe ens data hvis kundens virksomhed brænder ned?
>
> Der er den tredje mulighed som lidt er et kompromis med sikkerheden:
> 3) Ansvaret ligger hos mig: Jeg kryptere kodeordene og har mulighed for at
> dekryptere kodeordene igen ved brug af en "master-kode". Problemet ligger
i
> at med flere ansatte der skal administrere systemet bliver dette systemet
> måske endnu mere usikkert end mulighed 1.

Du kan vel i din database tillade andre brugere at tilføje nye koder, men
ikke se de gamle.
(også tildele nye koder til eksisterende kunder, men hvor du gemmer
historik)

> Nogle gode råd eller ideer til hvordan jeg bør forholde mig til dette
> problem?

Du har to lister. En med kundernes brugernavn hvoraf der fremgår et tal
(mellem et og 1000)
En liste med tallene 1 til 1000 hvor kundernes kodeord fremgår.
De to lister opbevares adskilt...

Men jeg ville nu vælge løsningen med en database hvor alle administratorerne
kan tilføje nye kodeord, men ikke se gamle.


Rune

---

"Thomas Eg Jørgensen" <tejo03@kom.auc.dk> wrote in message
news:cu3fnu$24vf$1@news.cybercity.dk...
[snip]
>
> Nogle gode råd eller ideer til hvordan jeg bør forholde mig til dette
> problem?
>

Jeg vil starte med at indrømme jeg på ingen måde er ekspert indenfor
kryptografi.

Men jeg vil mene den bedste løsning ville være at du opbevarede brugernes
password krypteret. Men som du selv påpeger så ligger problemet nu i
hvorledes du beskytter nøglen til denne kryptering.
Til dette ville jeg mene en form for secret sharing ville være på sin plads.
Secret sharing er en metode til at sikkre 2 ting:
1. Ingen individuel person kender hele sandheden
2. Hvis en del af sandheden går tabt kan den genskabes fra de andre
personer.

Det man normalt snakker om er at man tager krypteringsnøglen og vha. en
passende algoritme splitter denne på i n shares. Algoritmen definere et
såkaldt threshold t der er 0 < t < n.
Idéen er nu at såfremt t shares er kendt afslører det intet om hvilken nøgle
der er brugt, men hvis man har t + 1 shares er nøgle entydigt bestemt.

Det mest simple setup for dig ville være at følgende personer fik hver deres
share:
1. Kunden
2. Dig
3. Troværdig 3. part (f.eks. banken)

Og I satte et threshold på 2. Såfremt kundens hus sprang i luften, ville
kunden kunne gå ned i banken hente den 3. share og sammen med dig få hans
kodeord.

Hvad der findes af kommecielle produkter der implementere ovenstående ved
jeg dog ikke lige. Men her er lidt læse stof til at skubbe dig igang:
http://en.wikipedia.org/wiki/Secret_sharing
http://www.daimi.au.dk/~ivan/secretsharing.ps (Bemærk: PostScript
format, men GhostView burde kunne læse det for dig)

Hilsen
Mads

---

"Mads" <mads@iname.com> wrote in message
news:cu8cfv$159i$1@news.cybercity.dk...
>
> Og I satte et threshold på 2. Såfremt kundens hus sprang i luften, ville
> kunden kunne gå ned i banken hente den 3. share og sammen med dig få hans
> kodeord.
>
Ups... der var en lille fejl. Der skulle have stået:
"...I satte et threshold på 1..."

Hilsen Mads

---

"Mads" <mads@iname.com> wrote in message
news:cu8cfv$159i$1@news.cybercity.dk...
> [snip]
>
> Hvad der findes af kommecielle produkter der implementere ovenstående ved
> jeg dog ikke lige.
>

Jeg sad lige og søgte lidt på emnet og faldt over et patent PGP har udtaget:
http://www.pgp.com/news/2004/keyreconpatent.html
Åbenbart har de patenteret en eller anden form for Secret Sharing. Så man må
antage at PGP laver nogle produkter til dette.
Man kan så undre sig over hvorledes man kan patentere noget således. Men det
er jo en anden diskussion.

Hilsen
Mads