Opslaan van wachtwoorden

[Verwijderd]

Ik ben bezig met een programmaatje (in Delphi) die je email can checken. Daarvoor moet ik wel wat gegevens in 't Register opslaan zoals gebruikersnaam, wachtwoord, mailserver, etc. Nu wil ik natuurlijk niet dat het wachtwoord zo maar door jan en alleman is uit te lezen uit het Register.

Heeft iemand een idee hoe ik zo'n wachtwoord het beste kan opslaan (in het Register of eventueel ergens anders op schijf) met een beetje adequate beveiliging? Als iemand anders dan m'n programmaatje toch dat wachtwoord weet terug te vinden, dan heb ik liever niet dat ik het had opgeslagen als gewone platte tekst...

Het zal uiteraard op een of andere manier ge-encrypt moeten worden, maar hoe?

[Verwijderd]

Het maakt niet uit waar je het opslaat. Het enige dat uitmaakt is hoe. Persoonlijk zal ik iets als 3DES of AES eroverheen halen. Dat is tamelijk moeilijk (onmogelijk voor gewone stervelingen) te kraken, en zeer makkelijk te implementeren.

Het zal niet zo moeilijk zijn om hier een goede Delphi implementatie voor te vinden.

/Edit: Er was hier trouwens laatst nog een topic over, dus mischien heb je daar wat aan

/Edit2: Zie ook http://www.esat.kuleuven.ac.be/~rijmen/rijndael/

[Gerco]

Windows heeft een CryptoAPI, of je dat gewoon zonder certificaten kunt gebruiken weet ik niet, maar het beheerst iig Blowfish en 3DES, die zijn ruim veilig genoeg.

[Verwijderd]

Bdankt lui, ik zal eens kijken!

[SuperRembo]

Op maandag 20 mei 2002 15:33 schreef KoenM het volgende:
Het maakt niet uit waar je het opslaat. Het enige dat uitmaakt is hoe. Persoonlijk zal ik iets als 3DES of AES eroverheen halen. Dat is tamelijk moeilijk (onmogelijk voor gewone stervelingen) te kraken, en zeer makkelijk te implementeren.

Dat is dus niet wat Aegis zoekt. Hij wil een wachtwoord opslaan in de registry om het er later weer uit te halen om in te kunnen loggen bij de mailserver.

[Glimi]

Op maandag 20 mei 2002 16:09 schreef SuperRembo het volgende:

[..]

Dat is dus niet wat Aegis zoekt. Hij wil een wachtwoord opslaan in de registry om het er later weer uit te halen om in te kunnen loggen bij de mailserver.

Wat is er mis met het encoderen, naar het register schrijven, ophalen uit het register en decoderen?

3DES is geen hash ofzo hoor

[SuperRembo]

Op maandag 20 mei 2002 16:18 schreef Glimi het volgende:
3DES is geen hash ofzo hoor

OK, mijn fout

[TheOneLLama]

Op maandag 20 mei 2002 16:18 schreef Glimi het volgende:

[..]

Wat is er mis met het encoderen, naar het register schrijven, ophalen uit het register en decoderen?

3DES is geen hash ofzo hoor

Als dat programma van hem het kan uitlezen kan iedereen dat natuurlijk.. 3DES is duidelijk niet voor dit soort dingen bedoeld.

[Verwijderd]

Op maandag 20 mei 2002 18:25 schreef TheOneLLama het volgende:
Als dat programma van hem het kan uitlezen kan iedereen dat natuurlijk.. 3DES is duidelijk niet voor dit soort dingen bedoeld.

Tuurlijk wel. De truc is namelijk dat je de data alleen kan uitlezen als je het juiste password weet. Anders kan je het echt niet bekijken hoor (zou leuk zijn ).
Als je gewoon een heel moeilijk password neemt ala: 'Niema@ndDieDitOOOOOitKenRade' dan zal niemand dat ooit decrypten, behalve jij zelf, want jij kent het wachtwoord wel

[TheOneLLama]

Op maandag 20 mei 2002 18:37 schreef KoenM het volgende:

[..]

Tuurlijk wel. De truc is namelijk dat je de data alleen kan uitlezen als je het juiste password weet. Anders kan je het echt niet bekijken hoor (zou leuk zijn ).
Als je gewoon een heel moeilijk password neemt ala: 'Niema@ndDieDitOOOOOitKenRade' dan zal niemand dat ooit decrypten, behalve jij zelf, want jij kent het wachtwoord wel

Dat veranderd nog niet dat 3DES hier niet voor bedoeld is... met een beetje tools kan ik er zo achter komen welk wachtwoord je in je progje gebruikt (aangezien dat dan hardcoded in je prog zit dan). Hoef niks te raden dan

[Verwijderd]

Op maandag 20 mei 2002 18:49 schreef TheOneLLama het volgende:
Dat veranderd nog niet dat 3DES hier niet voor bedoeld is... met een beetje tools kan ik er zo achter komen welk wachtwoord je in je progje gebruikt (aangezien dat dan hardcoded in je prog zit dan). Hoef niks te raden dan

Als ik het wachtwoord in 5 delen splits, en alle delen op andere plaatsen bewaar, en dan in 3x aan elkaar plak, dan hoop ik dat je er niet achter gaat komen...

Hoe zou je anders 3DES kunnen/moeten gebruiken

[zerok]

Ik ben wel benieuwd hoe je dat wil doen met het wachtwoord?
als je zoiets als 3des moet je programma of om het wachtwoord vragen of hardcoded er in hebben zitten. Zie ik hier wat over het hoofd??
Als je het wachtwoord moet invoeren kan je net zo goed je e-mail wachtwoord onthouden. Hardcoded is nou nie echt veilig zeker als je je programma gaat verspreiden.

[Verwijderd]

Op maandag 20 mei 2002 19:14 schreef zerok het volgende:
Hardcoded is nou nie echt veilig zeker als je je programma gaat verspreiden.

Waarom zou dit niet veilig zijn? Ik kan niet echt een reden bedenken waarom je het wachtwoord niet hard-coded maakt. Wat zie ik dan over het hoofd?

[TheOneLLama]

Op maandag 20 mei 2002 19:06 schreef KoenM het volgende:

[..]

Als ik het wachtwoord in 5 delen splits, en alle delen op andere plaatsen bewaar, en dan in 3x aan elkaar plak, dan hoop ik dat je er niet achter gaat komen...

Hoe zou je anders 3DES kunnen/moeten gebruiken

Dan draai ik je progje in debug mode en kijkt wat ie allemaal doet.. dan vervang ik het dlltje / stukje code waar je 3DES aanroept met je key.. etc. etc. Dit is echt makkelijker te kraken dan je denkt. Wat jij wilt is "security through obscurity". Dit kan dan wel niet iedere user doen, maar er hoeft maar 1 russische cracker te zijn die dit 's avonds ff in een paar minuten doet en jou l33tgeheimec0de raad, een tooltje bouwt en het op astalavista.box.sk zet.

3DES (en de andere genoemde voorbeelden hier) is niet bedoeld om lokaal passwords op te slaan, 3DES is bedoeld om dataverkeer tussen 2 punten te encrypten, en ervoor te zorgen dat als punten hiertussen dit verkeer afluisteren ze er niks aan hebben..

Voor lokale passwords opslaan om tegen te authenciceren (en die kunnen natuurlijk ook via bv 3DES van een remote komen) maakt van gebruik van 1 way encryptie. Dan wordt niet het daadwerkelijk het wachtwoord opgeslagen maar iets anders. Pas als je een wachtwoord probeerd kan gecontroleerd worden of dit de goede is of niet en pas als je de goee probeert komt eruit dat dat ww is goed. Zonder het goede WW weet de computer dus ook niet wat het WW is. Oftwel daar heeft de poster nog niks aan..

Conclusie: als je dit wachtwoord lokaal wilt bewaren zal het altijd relatief gemakkelijk te achterhalen zijn (als gebruik je 1024bit encryptie). Dat kun je dus ook maar beter niet doen wat dat geeft misschien een vals gevoel van veiligheid. Als je het niet plaintext in je registry wilt hebben kun je het altijd wel een beetje versleutelen natuurlijk, denoods gewoon XORen ofzo. Misschien dat er wat windows API is om het te versleutelen met je windows login? (dan kunnen andere gebruikers er in ieder geval niet zomaar iets mee).

[Verwijderd]

Op maandag 20 mei 2002 19:38 schreef TheOneLLama een zeer helder verhaal

Maar hoe slaan de meeste programma's hun passwords dan op . Die maken volgens mij toch echt gebruik van 2-way encryptie, en volgens jouw vehaal is dat hele idee onveilig.

Persoonlijk zou ik het iets minder zwart/wit stellen. Want hoe groot is nou de kans dat een russische hacker precies het programma van de topic starter wil cracken?
Voor bedrijfskritische opslag is het mischien niet geschikt, maar voor huis-tuin-en-keuken werk wel, lijkt me.

Dan is een 1024 bits encoding mischien wel overkill, maar 3DES is toch wel een ontzettend veel veiliger dan plain text...

[SWfreak]

Op maandag 20 mei 2002 19:49 schreef KoenM het volgende:

Maar hoe slaan de meeste programma's hun passwords dan op . Die maken volgens mij toch echt gebruik van 2-way encryptie, en volgens jouw vehaal is dat hele idee onveilig.

Persoonlijk zou ik het iets minder zwart/wit stellen. Want hoe groot is nou de kans dat een russische hacker precies het programma van de topic starter wil cracken?
Voor bedrijfskritische opslag is het mischien niet geschikt, maar voor huis-tuin-en-keuken werk wel, lijkt me.

Dan is een 1024 bits encoding mischien wel overkill, maar 3DES is toch wel een ontzettend veel veiliger dan plain text...

Alles is veiliger dan plain-text. Als de topicstarter zn proggie alleen thuis wil gebruiken is er natuurlijk geen probleem, maar dan kan ie het in principe ook in plain tekst opslaan. Als je het proggie echter wil verspreiden, dan is er een zeer grote kans dat het onder de aandacht komt van een russische hacker die dan heel makkelijk jou encryptie hackt. Niet zo plezierige reclame...

[Verwijderd]

Hmmm, het was inderdaad we de bedoeling om het eventueel te verspreiden via het internet, dus dan zou ik inderdaad wel wat beters willen dan een encryptie zoals "schuif alle letters in het alfabet eentje op". Ik heb eventjes zitten zoeken op verschillende sites zoals Torry.net, maar het is verdomd lastig om een een simpel iets te komen wat gewoon een simpele string vrij goed kan encrypten (en het tegenovergestelde), zonder een hele mikmak aan bits and randseed-achtige dingen te doen

[TheOneLLama]

Op maandag 20 mei 2002 19:49 schreef KoenM het volgende:

[..]

Maar hoe slaan de meeste programma's hun passwords dan op . Die maken volgens mij toch echt gebruik van 2-way encryptie, en volgens jouw vehaal is dat hele idee onveilig.

M$ gebruikt nogal eens de Power of XOR(tm)
De veiligste manier blijft 1-way encryptie.. maar dat betekend dus dat je idd je password niet kan/moet cachen.

Persoonlijk zou ik het iets minder zwart/wit stellen. Want hoe groot is nou de kans dat een russische hacker precies het programma van de topic starter wil cracken?

Tja, dat is die houding van.. wie wil er nou *mijn* progje hacken? Zo zijn er meer de fout in gegaan natuurlijk.. Als toch niemand *jouw* prog wil hacken sla het dan met een simpele XOR op.

Voor bedrijfskritische opslag is het mischien niet geschikt, maar voor huis-tuin-en-keuken werk wel, lijkt me.
Dan is een 1024 bits encoding mischien wel overkill, maar 3DES is toch wel een ontzettend veel veiliger dan plain text...

Het blijft "obscrurity" en niet security.. de veiligheid van je data is totaal niet meer afhankelijk van de lengte van je key maar van hoe goed je weet te verstoppen waarmee je je data versleuteld. Je roept waarschijnlijk een dll aan voor 3DES dus dat is een kwestie van 1 keer een wrapper schrijven voor die DLL en dan kunnen alle progjes die deze "beveiliging" gebruiken binnen 1 minuut gekraakt worden.

Misschien dat je dan beter zelf nog een versleutel algoritme kan maken met bijvoorbeeld de

code:

synchronized protected int next(int bits) {
     seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
     return (int)(seed >>> (48 - bits));
 }

functie (java in dit geval).. gewoon een beetje kloten dat als ze het willen breken ze toch echt ook even je prog moeten reverse engineren en niet alleen de call naar een andere DLL hoeven af te vangen..

BV een hash opslaan waarvan het eerst deel een getal / getallen zijn die naar een seed / seeds verwijzen (die je dus weer random kiest) en het tweede deel van de hash het daadwerkelijk password geXORed met de getallen die uit die seeds komen

Het blijft obscurity maar passwords "cachen" is gewoon niet secure (zolang je zo uiteindelijk plaintext nodig hebt voor bv pop3 in dit geval)...

[zerok]

Op maandag 20 mei 2002 19:30 schreef KoenM het volgende:
Waarom zou dit niet veilig zijn? Ik kan niet echt een reden bedenken waarom je het wachtwoord niet hard-coded maakt. Wat zie ik dan over het hoofd?

onder linux bijvoorbeeld heb je een commando strings en dan zie je alle hard coded strings dat is wat er niet veilig aan is. Iedere hex editor heeft ook wel een string zoek functie

[Verwijderd]

HMZ gebruik bv zoiets voor je codering : gecodeerde zooi is : (map waarin je EXE staat) + (E-Mail wachtwoord) + (je windows inlognaam) , is voor een hacker al moeilijker te achterhalen wat die gegevens zijn, je kan ook andere vaste gegevens bedenken zoals je windows OEM code of de tijd waarop je EXE op je comp gezet is.
kortom als iemand die sleutel in handen krijgt en hij heeft ook nog eens je programma doorgesnuffelt dan moet ie ook nog al die info zien te krijgen voor dat dit boosaardige persoon je w8woord kan achterhalen

[Verwijderd]

Het is al een keer half genoemd, maar bij deze nog een keer en dan wat duidelijker. Als jij gewoon plain POP gebruikt dan heeft het niet al te veel zin veel moeite te steken in het encrypten van dat wachtwoord omdat het toch gewoon in plain text over de lijn wordt gestuurd (waarom gebruikt iedereen het eigenlijk nog steeds in een tijdperk waarin miljoenen mensen bezig zijn druk maken of de zoveelste security bug??).
Een simpele sniffer of een mega simpel socket servertje die doet alsof ie een meelserver is maken het dan dus heel erg makkelijk je wachtwoord te achterhalen. Kortom, als je encryptie wel interessant vindt steek er dan vooral tijd in, maar anders...

[RickN]

Natuurlijk is het niet veilig om wachtwoorden lokaal op te slaan, daar zijn wachtwoorden ook niet voor hè. We zijn met z'n allen gewoon te lui om onze wachtwoorden even in te typen als we onze mail willen lezen en dan is het niet meer veilig nee.

[Verwijderd]

Op dinsdag 21 mei 2002 23:44 schreef RickN het volgende:
Natuurlijk is het niet veilig om wachtwoorden lokaal op te slaan, daar zijn wachtwoorden ook niet voor hè. We zijn met z'n allen gewoon te lui om onze wachtwoorden even in te typen als we onze mail willen lezen en dan is het niet meer veilig nee.

Maar we hoeven ook niet paranoide te worden..

[Tomatoman]

Op dinsdag 21 mei 2002 20:28 schreef hondass50 het volgende:
[...] Als jij gewoon plain POP gebruikt dan heeft het niet al te veel zin veel moeite te steken in het encrypten van dat wachtwoord omdat het toch gewoon in plain text over de lijn wordt gestuurd [...]

1. Daar heb je een goed punt.
2. Het lijkt me dat je een e-mailwachtwoord niet zo goed hoeft te beveiligen als bijvoorbeeld een financiële administratie. Ik zou die encryptie dan ook niet te ingewikkeld maken. Bij heel veel mailgebruikers is het een stuk gemakkelijker om hun wachtwoord met wat common sense te raden dan jouw registersleutels te ontcijferen . Het meest gebruikte wachtwoord ter wereld is... secret. Hoezo voorspelbaar?

[TheOneLLama]

Op woensdag 22 mei 2002 01:44 schreef tomatoman het volgende:

[..]
Het meest gebruikte wachtwoord ter wereld is... secret. Hoezo voorspelbaar?

In Engeland laatst ook zo'n onderzoek geweest..
daar was password het meest gebruikt..
Soms vraag ik me echter af of dit misschien zo is omdat alleen mensen die zo dom zijn zo'n password te kiezen aan dit soort onderzoeken willen mee te werken

[Crazy D]

Op woensdag 22 mei 2002 12:32 schreef TheOneLLama het volgende:
In Engeland laatst ook zo'n onderzoek geweest..
daar was password het meest gebruikt..
Soms vraag ik me echter af of dit misschien zo is omdat alleen mensen die zo dom zijn zo'n password te kiezen aan dit soort onderzoeken willen mee te werken

Tjah hoe serieus geef je antwoord als iemand je vraagt "wat is jouw password"

[Dido]

Op woensdag 22 mei 2002 14:42 schreef Crazy_D het volgende:

[..]

Tjah hoe serieus geef je antwoord als iemand je vraagt "wat is jouw password"

Mwah... ik ken tenminste een persoon die her en der password als password gebruikt...

[TheOneLLama]

Op woensdag 22 mei 2002 15:03 schreef Dido het volgende:

[..]

Mwah... ik ken tenminste een persoon die her en der password als password gebruikt...

Ik ook 1 iemand.. ik denk dat als je zo'n onderzoek op de hotmail servers bv. gaat houden dat je d'r wel een stuk meer tegen komt

[Crazy D]

Op woensdag 22 mei 2002 17:42 schreef TheOneLLama het volgende:
Ik ook 1 iemand.. ik denk dat als je zo'n onderzoek op de hotmail servers bv. gaat houden dat je d'r wel een stuk meer tegen komt

Ja waarschijnlijk wel, maar ja, nou noem je ook wel iets
Mjah dat er belachelijke wachtwoorden worden gebruikt (cq. gebruikt mogen worden...). 1234, en als het tijd is om het te veranderen wordt het 1235

[Verwijderd]

ehhh, volgens mij gaat dit hard richting off-topic en ik vind het toch wel een interresant topic .

Om zelf maar het goede voorbeeld te geven:
Wat me nog altijd niet duidelijk is geworden is hoe een gewoon programma z'n wachtwoorden encrypt.
Neem (het ons aller geliefde ) IE. Hierin kan je aangeven dat bepaalde wachtwoorden opgeslagen worden.
Ik neem aan dat deze wachtwoorden ook gewoon met 2-way encryptie worden opgeslagen, en niemand heeft het password hier nog van geraden (gelukkig maar ), dus hoe doen zij het?

[TheOneLLama]

Op woensdag 22 mei 2002 20:00 schreef KoenM het volgende:
ehhh, volgens mij gaat dit hard richting off-topic en ik vind het toch wel een interresant topic .

Om zelf maar het goede voorbeeld te geven:
Wat me nog altijd niet duidelijk is geworden is hoe een gewoon programma z'n wachtwoorden encrypt.
Neem (het ons aller geliefde ) IE. Hierin kan je aangeven dat bepaalde wachtwoorden opgeslagen worden.
Ik neem aan dat deze wachtwoorden ook gewoon met 2-way encryptie worden opgeslagen, en niemand heeft het password hier nog van geraden (gelukkig maar ), dus hoe doen zij het?

http://www.elcomsoft.com/aiepr.html

Misschien weten hun daar iets meer van?

Dit is volgens mij hetzelfde bedrijf van die russische hacker die in de US is aangeklaagd voor het kraken van E-Book "encryptie".

[Tomatoman]

Omdat niemand een concreet voorbeeld geeft van die befaamde xor-versleuteling, zal ik dat zelf doen. Het is echt doodeenvoudig.

code:

type
  TFixedLengthString = string[255];
const
  Key = $AA; // willekeurige waarde in [1..$FF], dit is de coderingssleutel
  { Let op: de coderingssleutel mag niet in de te coderen string voorkomen!
    $AA is geen probleem, want dat is het karakter 'ª' (komt waarschijnlijk
    niet in een wachtwoord voor). }

function Encode(const S: string): TString255;
var
  n: Integer;
begin
  if Length(S) > 254 then
    raise Exception.Create('String mag hooguit 254 karakters lang zijn.');

  { string encrypten met xor functie }
  for n := 1 to Length(S) do
    Result[n] := Char(Byte(S[n]) xor Key);

  { rest van het resultaat vullen met random waarden (groter dan 0) }
  for n := Length(S) +1 to 254 do
    Result[n] := Char(Random($FE) +1);

  { in de 255e byte de lengte van de originele string opslaan, byte
    encrypten met xor functie }
  Result[255] := Char(Length(S) xor Key);

  Length(Result) := 255;
end;

function Decode(const S: TString255): string;
var
  n: Integer;
  Decoded: TString255;
begin
  { eerst de lengte van de originele string achterhalen }
  Length(Decoded) := Byte(S[255]) xor Key;

  { string ontcijferen met xor }
  for n := 1 to Length(Decoded) do
    Decoded[n] := Char(Byte(S[n]) xor Key);

  Result := Decoded;
end;

Een met Encode versleuteld wachtwoord is echt ongelooflijk eenvoudig te ontcijferen als je weet hoe het werkt, maar een willekeurige gebruiker die toevallig zo'n versleuteld wachtwoord in het Windows register tegenkomt zal flink geïntimideerd zijn en er niet aan beginnen. Het is natuurlijk niet bedoeld om echte hackers tegen te houden.

[Soultaker]

Op donderdag 23 mei 2002 17:11 schreef tomatoman het volgende:
Let op: de coderingssleutel mag niet in de te coderen string voorkomen! $AA is geen probleem, want dat is het karakter 'ª' (komt waarschijnlijk niet in een wachtwoord voor).

Hmm, ik heb het niet zo op 'waarschijnlijk'. Het is meestal geen probleem om met binaire data te werken (de Windows registry heeft daar bijvoorbeeld geen moeite mee) en dan heb je die restrictie natuurlijk niet.

Waarom sla je trouwens de lengte van de originele string op, als je al weet dat je geen nul-karakters in je gecodeerde string hebt?

Bovendien beperk je het aantal mogelijke codesleutels nogal op deze manier; eigenlijk zijn zo alleen de 32 'onderste' karakters en enkele karakters uit de bovenste helft van de ASCII-tabel bruikbaar.

Stukje C code ter illustratie:

code:

const char sleutel=0xFF;

void encode(unsigned char *str)
{
  while(*str) *(str++)^=sleutel;
}

void decode(unsigned char *str, int len)
{
  while(len--) *(str++)^=sleutel;
}

Natuurlijk moet de code die encode aanroept ervoor zorgen dat de lengte van de string str ergens opgeslagen wordt.

[TheOneLLama]

Op donderdag 23 mei 2002 17:11 schreef tomatoman het volgende:
Omdat niemand een concreet voorbeeld geeft van die befaamde xor-versleuteling, zal ik dat zelf doen. Het is echt doodeenvoudig.

Maar goed, het moge dus duidelijk zijn dat iedere MAVO schoolverlater met wiskunde A zo'n XOR encryptie kan breken Het is praktisch hetzelfde als plaintext opslaan..

[zerok]

Volgend mij is het probleem van de simpele encrypties zoals de xor is dat het 'veilig' zolang niemand weet hoe het werkt. Zeker als je de source gaat verspreiden kan je net zo goed niet encrypten en het gewoon onder een niet zo'n opvallende naam opslaan.
Als je de source niet gaat verspreiden en je acht de eventueele gebruikers niet zo hoog dat ze de encryptie kunnen breken dan is het goed genoeg maar als je een commercieel programma maakt is dit wel een erge bug.

[TheOneLLama]

Op donderdag 23 mei 2002 19:32 schreef zerok het volgende:
Volgend mij is het probleem van de simpele encrypties zoals de xor is dat het 'veilig' zolang niemand weet hoe het werkt. Zeker als je de source gaat verspreiden kan je net zo goed niet encrypten en het gewoon onder een niet zo'n opvallende naam opslaan.
Als je de source niet gaat verspreiden en je acht de eventueele gebruikers niet zo hoog dat ze de encryptie kunnen breken dan is het goed genoeg maar als je een commercieel programma maakt is dit wel een erge bug.

XOR is gewoon zeer onveilig omdat het *te* simpel is.. ook zonder source of reverse engineren kun je er zo achterkomen, het is een kwestie van een paar keer een wachtwoord invullen en opslaan en dan heb je het al. Een seed algoritme in combinatie met XOR in 1 of andere hash stoppen daartegen kost een stuk meer moeite. Als je idd de source erbij gaat meeleveren kun je het net zo goed niet doen nee