[PHP] encrypt / decrypt

[Verwijderd]

Voor mijn werk ben ik een wachtwoord module aan het maken binnen ons eigen ontwikkelde CRM systeem. In deze module komen al de wachtwoorden te staan die bij klanten gebruikt worden etc (IT dienstverlener).

Het is de bedoeling dat deze wachtwoorden als plain tekst opgevraagd kunnen worden, maar uiteraard willen we ze niet als plain text opslaan in de database. Eigenlijk wil ik dus een encrypted string in de database zetten en deze decrypted weergeven op het scherm.

Ik heb al gekeken naar enige opties, zoals mcrypt. Helaas krijg ik dit niet 100% werkend, dus ipv van me hier op blind te staren ben ik benieuwd of er nog meerdere opties bestaan.

Het gaat dus om PHP / MySQL. Ik ben benieuwd hoe menig programmeur dit op zou lossen.

[Noork]

Je zou iets als rott13 kunnen gebruiken

...maar serieus, wat werkt er dan niet goed? Voor alternatieven zie b.v. PHP Pear packages, http://pear.php.net/packa...atname=Encryption&php=all

[mithras]

Het wachtwoord plaintext opslaan of encrypted waarmee je het tot plaintext kan terughalen heeft geen tot nauwelijks verschil voor je beveiliging.

Imho is je model al verkeerd door aan te nemen dat het tot plain text terug te transformeren moet zijn. Ter bevordering van de veiligheid zou ik eerst dit toch echt nog even aan de kaak stellen! Mocht je echt genoodzaakt zijn om toch deze eis te houden, zou je kunnen kijken naar exec() en gpg. Maar goed, als ze uiteindelijk in je database komen, is het waarschijnlijk ook niet zo moeilijk om een php scriptje te plaatsen wat al je wachtwoorden decrypt...

[Verwijderd]

Genoodzaakt deze eis te houden? Als dit niet mogelijk is valt het hele concept van de module in het water..

[Voutloos]

Ja, dus? De module is toch niet het doel maar een middel?

[Cartman!]

Volgens mij is de mcrypt module zeker iets wat je kunt gebruiken, wat lukte daar niet mee?

Verder ben ik het eigenlijk alleen maar eens met mithras: je moet nooit terugwillen naar een plaintext versie maar gewoon een nieuw wachtwoord sturen wat iemand zelf weer kan veranderen.

[mithras]

Verwijderd schreef op dinsdag 31 maart 2009 @ 09:55:
Genoodzaakt deze eis te houden? Als dit niet mogelijk is valt het hele concept van de module in het water..

Als het bijvoorbeeld een doel is om vergeten wachtwoorden terug te halen, dan hoeft dat niet met dit systeem. Het is ook mogelijk om een activatiesleutel aan te maken en deze een bepaalde periode te laten gelden. Wanneer je een (web)pagina bezoekt en in die juiste periode de gebruikersnaam + activatiesleutel kan invoeren, mag je je eigen wachtwoord resetten. Zo'n systeem is veel veiliger dan wanneer je bij het wachtwoord vergeten een mailtje kan sturen met daarin het wachtwoord.

Mocht dit niet het doel zijn van die module, maar is er een ander punt, is daar (waarschijnlijk) ook wel een oplossing voor te verzinnen

Cartman! schreef op dinsdag 31 maart 2009 @ 09:58:
Volgens mij is de mcrypt module zeker iets wat je kunt gebruiken, wat lukte daar niet mee?

Verder ben ik het eigenlijk alleen maar eens met mithras: je moet nooit terugwillen naar een plaintext versie maar gewoon een nieuw wachtwoord sturen wat iemand zelf weer kan veranderen.

En dan kan je @random van gebruikers wachtwoorden resetten Wanneer je met sleutels werkt, heb je (bijv) 24h de tijd om je wachtwoord te veranderen. Je kan zo'n "activatie" ook negeren, waardoor je wachtwoord ongewijzigd blijft. Hierdoor kan je eigenlijk alleen je eigen wachtwoord resetten

[ Voor 28% gewijzigd door mithras op 31-03-2009 10:02 ]

[Rukapul]

Als ik TS begrijp wil hij gewoon een online password manager maken?

Indien ja, dan is geencrypt opslaan slechts het begin. Tweede stap is namelijk om de geencrypte data en de bijbehorende sleutel(s) niet (geheel) op dezelfde locatie op te slaan. Dit is zowel ter bescherming van interne aanvallen alswel ter bescherming van externe aanvallen. Uitdaging dus om een ontwerp te maken waar (een stukje van) de sleutel niet op de machine zelf staat

[ Voor 77% gewijzigd door Rukapul op 31-03-2009 10:09 ]

[Verwijderd]

Volgens mij hebben cartman en mithras het niet bij het juiste eind. Volgens mij wil de TS inderdaad iets van een password manager maken, om zo wachtwoorden van klanten in een CRM systeem te kunnen opslaan (bijvoorbeeld wachtwoorden van de servers van de klant oid). Dan zul je inderdaad moeten kunnen encrypten/decrypten.

Verder ben ik het met rukapul eens: Sla de gegevens niet op dezelfde locatie op, anders is het maar schijnveiligheid.

Mcrypt lijkt inderdaad precies te doen wat jij zoekt. Anders zou je hier naar kunnen kijken: phpAes.

[ Voor 14% gewijzigd door Verwijderd op 31-03-2009 10:27 ]

[Verwijderd]

Verwijderd schreef op dinsdag 31 maart 2009 @ 10:25:
Volgens mij hebben cartman en mithras het niet bij het juiste eind. Volgens mij wil de TS inderdaad iets van een password manager maken, om zo wachtwoorden van klanten in een CRM systeem te kunnen opslaan (bijvoorbeeld wachtwoorden van de servers van de klant oid). Dan zul je inderdaad moeten kunnen encrypten/decrypten.

Precies.

Het probleem wat ik met mcrypt had is dat er allerlei rare tekens achter het geencrypte wachtwoord tevoorschijn kwamen, deze code gebruikte ik ervoor:

PHP:

<?php
$key = "this is a secret key";
$input = "Let us meet at 9 o'clock at the secret place.";

$td = mcrypt_module_open('tripledes', '', 'ecb', '');
$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
mcrypt_generic_init($td, $key, $iv);
$encrypted_data = mcrypt_generic($td, $input);
mcrypt_generic_deinit($td);
mcrypt_module_close($td);

echo "Encrypt: ".$encrypted_data;

echo "<br><br>";

$td = mcrypt_module_open('tripledes', '', 'ecb', '');
$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
$key = substr($key, 0, mcrypt_enc_get_key_size($td));
mcrypt_generic_init($td, $key, $iv);
$decrypted_data = mdecrypt_generic($td, $encrypted_data);
echo "Decrypt: ".$decrypted_data;
mcrypt_generic_deinit($td);
?>

[ Voor 55% gewijzigd door Verwijderd op 31-03-2009 10:44 ]

[Rukapul]

Misschien moet je je nog even verdiepen in het concept blockcipher...

En nee, ik ga het antwoord niet voorkauwen. Ik verwijs hiervoor naar een uitspraak van Bruce Schneier waarin hij zei liever nooit Applied Cryptograpy geschreven te hebben, omdat er geen ander boek is waardoor zoveel mensen dachten zelf wel security en crypto oplossingen te kunnen maken terwijl dat niet zo was: "Applied Cryptography did foster the inclusion of cryptography in many, many commercial products around the world. Many of those systems weren't very good, unfortunately, but that's another story."

[ Voor 91% gewijzigd door Rukapul op 31-03-2009 10:51 ]

[Verwijderd]

Rukapul schreef op dinsdag 31 maart 2009 @ 10:44:
Misschien moet je je nog even verdiepen in het concept blockcipher...

En nee, ik ga het antwoord niet voorkauwen. Ik verwijs hiervoor naar een uitspraak van Bruce Schneier waarin hij zei liever nooit Applied Cryptograpy geschreven te hebben, omdat er geen ander boek is waardoor zoveel mensen dachten zelf wel security en crypto oplossingen te kunnen maken terwijl dat niet zo was.

"Niet voorkouwen" - Wetende dat iedere boer vandaag de dag in staat is om wikipedia te doorzoeken - Hypocriet.

Wikipedia: Blokvercijfering

[Verwijderd]

Alsnog wil je geen wachtwoorden opslaan. Gezien dit altijd een gevoelig punt zal zijn, en blijven. Er hoeft maar 1 securitylek in je CMS te zitten en alles ligt op straat.

Zoals Rukapul al schreef moet je dan ook nog op andere locaties delen gaan opslaan, etc. En dit is ook nog een schijnveiligheid, je moet namelijk op je server ook ergens de decryptie uitvoeren, stel dat een aanvaller dat stukje nou net in de gaten aanhet houden is, en daarmee een stream met unencrypted wachtwoorden ter beschikking heeft.

Als het bijvoorbeeld gaat om servers, gebruik dan aub iets als keys/certificates, om in te loggen op deze servers (bv sshkeygen, etc). Supporten je servers dit niet, upgrade ze dan eens naar een echt OS of gebruik echte software. Misschien op basis van dat cert + user cert, pas laten inloggen?
Hierdoor heb je nergens passwords opgeslagen, alleen de keys. Stuk veiliger, makkelijker te revoken.

[Rukapul]

Verwijderd schreef op dinsdag 31 maart 2009 @ 10:54:
[...]


"Niet voorkouwen" - Wetende dat iedere boer vandaag de dag in staat is om wikipedia te doorzoeken - Hypocriet.

Wikipedia: Blokvercijfering

Op basis van zo'n stuk tekst moet iemand in elk geval nadenken over de concepten

Verwijderd schreef op dinsdag 31 maart 2009 @ 10:59:
Zoals Rukapul al schreef moet je dan ook nog op andere locaties delen gaan opslaan, etc. En dit is ook nog een schijnveiligheid, je moet namelijk op je server ook ergens de decryptie uitvoeren, stel dat een aanvaller dat stukje nou net in de gaten aanhet houden is, en daarmee een stream met unencrypted wachtwoorden ter beschikking heeft.

Mwah, kwestie van gelaagd je security op orde krijgen:
• encryptie in DB beschermt bv tegen SQL injectie
• remote keys beschermen tegen lees-aanvallen op het filesysteem
etc.

De door jouw geschetste aanval is alweer een stuk bewerkelijker voor een externe aanvaller omdat het toegang tot de machine vereist (shell, fysiek) of aanpassing van de scripts (idem). Maargoed, dan kom je dus op zaken als:
• platform integriteit beschermt je tegen het monitoren van code

En zo kunnen we nog wel even doorgaan

Het is allerminst een voorbeeld van schijnveiligheid. Veiligheid is namelijk het bewust kiezen van welke risico's je wel en niet wilt/kunt lopen.

Als het bijvoorbeeld gaat om servers, gebruik dan aub iets als keys/certificates, om in te loggen op deze servers (bv sshkeygen, etc). Supporten je servers dit niet, upgrade ze dan eens naar een echt OS of gebruik echte software. Misschien op basis van dat cert + user cert, pas laten inloggen?
Hierdoor heb je nergens passwords opgeslagen, alleen de keys. Stuk veiliger, makkelijker te revoken.

TS heeft er geen controle over omdat het om wachtwoorden op infrastructuur van klanten gaat, niet van de eigen organisatie

[ Voor 3% gewijzigd door Rukapul op 31-03-2009 11:11 ]

[Cartman!]

Verwijderd schreef op dinsdag 31 maart 2009 @ 10:25:
Volgens mij hebben cartman en mithras het niet bij het juiste eind. Volgens mij wil de TS inderdaad iets van een password manager maken, om zo wachtwoorden van klanten in een CRM systeem te kunnen opslaan (bijvoorbeeld wachtwoorden van de servers van de klant oid). Dan zul je inderdaad moeten kunnen encrypten/decrypten.

Ah, nogmaals gelezen en nu snap ik idd wat de TS precies wil maken.

Het grote probleem is dat je die password wel kan opslaan maar de keys niet opgeslagen moeten worden op dezelfde plek. Anders kun je ze net zo goed plaintext opslaan want iemand die je DB ript pakt anders gewoon de source mee en tada...je key. Of je zou die files moeten encoden met iets als Zend Guard hoewel ik begreep dat dit ook weer te reversen is (niet 100%, maar genoeg om jouw keys te achterhalen).

[Verwijderd]

Hier een directe collega.

Het systeem in kwestie draait volledig op ons intranet, dit is een geïsoleerd netwerk wat op geen manier communiceert met het publieke netwerk. Erg vervelend dat ons aller tweaker (uitzonderingen daar gelaten) er blind vanuit gaat dat het aan beveiliging schort in plaats van een antwoord te geven op de vraag van de TS.

De encryptie zal enkel als "laatste linie" dienen wanneer er bijvoorbeeld intern gepoogd word het systeem te kraken(niet iedere medewerker mag bij ieder wachtwoord). Ook al gaan wij hier natuurlijk niet vanuit, beter voorkomen dan genezen.

Er hoeft maar 1 securitylek in je CMS te zitten en alles ligt op straat.

Je baseert je antwoord op de blinde assumptie dat dit het geval is, daarbij draait dit intern. De kans op misbruik is dus vrij klein.

stel dat een aanvaller dat stukje nou net in de gaten aan het houden is

Dit zou dan moeten gebeuren op netwerk niveau, de persoon die dat voor elkaar krijgt op ons intranet krijgt een baan aangeboden. (SSL is tevens aanwezig)

Als het bijvoorbeeld gaat om servers, gebruik dan aub iets als keys/certificates, om in te loggen op deze servers (bv sshkeygen, etc). Supporten je servers dit niet, upgrade ze dan eens naar een echt OS of gebruik echte software. Misschien op basis van dat cert + user cert, pas laten inloggen?
Hierdoor heb je nergens passwords opgeslagen, alleen de keys. Stuk veiliger, makkelijker te revoken.

Dit systeem zal niet enkel gebruikt worden voor "een paar servertjes" op "neppe OSs"(?). Het gaat hier om een cluster van enkele tientallen servers draaiende op Linux, Windows, Vmware. Deze voorzien onze klanten van diverse diensten als Terminal Services, Webservices, VoIP, VPS, Mail services, Spamfilter services en meer. Daarbij worden diverse administratieve wachtwoorden hier vastgelegd (denk aan portals van leveranciers)

Aangezien het hier om een grote diversiteit aan OSs en diensten gaat is het onmogelijk om hier voor keys te gaan genereren(het gaat bijvoorbeeld ook om gebruikswachtwoorden in de AD's).

Wat betreft het niet opslaan van de key op eenzelfde lokatie heb je volledig gelijk, dit zal ook niet het geval zijn.

Ik hoop dat het e.e.a. nu duidelijk is en dat er wat meer gericht geantwoord kan worden in plaats van het continue betwijfelen/afkeuren van motieven en beweegredenen. Verder zal ik mij terugtrekken van dit topic, kwade replies op dit bericht posten heeft geen zin.

[Cartman!]

Heel leuk je reactie (maak anders een eigen account, officieel niet toegestaan zo) maar we zijn er om mensen te helpen en dat wij het hebben over de beveiliging doen we niet om te neten maar om te zorgen dat er een veilige applicatie wordt gemaakt. Wij kunnen namelijk niet ruiken wat voor supergeisoleerd netwerk jij hebt. Het is fijn dat jij alle gebruikers vertrouwd maar toch zou ik er rekening mee houden dat iemand intern de boel probeert te hacken. Better safe than sorry.

Overigens staat er naar mijn idee een erg goed voorbeeld in de php-manual bij mcrypt_encrypt, wat daar nu mis mee is snap ik nog steeds niet?

http://nl.php.net/manual/en/function.mcrypt-encrypt.php

[ Voor 19% gewijzigd door Cartman! op 31-03-2009 11:51 ]

[Verwijderd]

Cartman! schreef op dinsdag 31 maart 2009 @ 11:47:
Heel leuk je reactie (maak anders een eigen account, officieel niet toegestaan zo) maar we zijn er om mensen te helpen en dat wij het hebben over de beveiliging doen we niet om te neten maar om te zorgen dat er een veilige applicatie wordt gemaakt.

Dit ís mijn eigen account
Ik doelde op de manier waarop commentaar (vaak) geleverd word, erg "minachtend en verwijtend".

-Nogmaals, ik heb het niet over iedere persoon die gereplied heeft in deze thread.

[ Voor 8% gewijzigd door Verwijderd op 31-03-2009 11:51 ]

[Cartman!]

Ik denk dat het gewoon een gezonde discussie is en de reacties die jij als "minachtend en verwijtend" bestempt bedoeld zijn om je op weg te helpen.

[Verwijderd]

Cartman, dat klopt, maar het is natuurlijk totaal overbodig om reacties te geven m.b.t. onze OS'en en er blind van uit gaan dat wij op 'neppe' software draaien. Dit is zover offtopic (in zekere zin).

Ik stel gewoon een vraag m.b.t. PHP code: ik wil weten wat nou, naast mcrypt, een algemene methode is om wachtwoorden te encrypten en decrypten. Het waarom ben ik zelf al achter.

Assumpties m.b.t. onze server beveiliging, CMS beveiliging etc heb ik weinig behoefte aan.

[Cartman!]

Dan had je dat wellicht in de TS kunnen vermelden. Het is eenmaal, naar mijn idee dan, niets meer dan extra 'service' dat we hier meedenken met het probleem en evt. al eerdere problemen kunnen oplossen danwel voorkomen.

Dan vraag ik mij nog steeds af: wat is er mis het mcrypt_encrypt() en wat is er mis met het eerder gezegde PEAR Encrypt en wat heb je verder allemaal uitgezocht om te kunnen encrypten?

[Verwijderd]

Cartman! schreef op dinsdag 31 maart 2009 @ 12:02:
Dan had je dat wellicht in de TS kunnen vermelden. Het is eenmaal, naar mijn idee dan, niets meer dan extra 'service' dat we hier meedenken met het probleem en evt. al eerdere problemen kunnen oplossen danwel voorkomen.

Dan vraag ik mij nog steeds af: wat is er mis het mcrypt_encrypt() en wat is er mis met het eerder gezegde PEAR Encrypt en wat heb je verder allemaal uitgezocht om te kunnen encrypten?

Er is niets mis met gezonde discussie, maar zoals gezegd vind ik het vrij irritant als er aannames gedaan worden en er dingen bij gehaald worden die totaal niet van belang zijn. Zoals:

Als het bijvoorbeeld gaat om servers, gebruik dan aub iets als keys/certificates, om in te loggen op deze servers (bv sshkeygen, etc). Supporten je servers dit niet, upgrade ze dan eens naar een echt OS of gebruik echte software. Misschien op basis van dat cert + user cert, pas laten inloggen?
Hierdoor heb je nergens passwords opgeslagen, alleen de keys. Stuk veiliger, makkelijker te revoken.

Kom op zeg. Hier zit ik toch niet op te wachten.

Wat betreft mcrypt, ik heb de code aangepast naar het volgende:

PHP:

<?php
$password = 'my secure password';
$key = 'ohitsgoodtoseewhatatangledwebweweave';
$iv = '12345678'; 

$cipher = mcrypt_module_open(MCRYPT_BLOWFISH,'','cbc','');

mcrypt_generic_init($cipher, $key, $iv);
$encrypted = mcrypt_generic($cipher,$password);
mcrypt_generic_deinit($cipher);

mcrypt_generic_init($cipher, $key, $iv);
$decrypted = mdecrypt_generic($cipher,$encrypted);
mcrypt_generic_deinit($cipher);

echo $encrypted;
echo $decrypted;

?>

Ook heb ik al base64 encoding/decoding er over heen gedaan, maar m'n $decrypted laat op zich de goede string zien maar heeft rare tekens op het einde, 6x �. De encrypted string ziet er uit als (Ó¢§Ö¦Ÿ’/¸0&¼$J2ºw!, wat op zich goed is, al weet ik niet zeker of m'n database daar van over de zeik gaat. Edit: nee, dat gaat prima. Het gaat nu dus puur om het decrypted wat op magische wijze verkeerd gaat.

[ Voor 15% gewijzigd door Verwijderd op 31-03-2009 12:09 ]

[mithras]

Verwijderd schreef op dinsdag 31 maart 2009 @ 11:18:
Hier een directe collega.

Het systeem in kwestie draait volledig op ons intranet, dit is een geïsoleerd netwerk wat op geen manier communiceert met het publieke netwerk. Erg vervelend dat ons aller tweaker (uitzonderingen daar gelaten) er blind vanuit gaat dat het aan beveiliging schort in plaats van een antwoord te geven op de vraag van de TS.

Het was mij niet duidelijk dat het om een password manager ging. Leuk hoor, passwords te kunnen decoderen, maar 99% van de php-programmeurs doen dit om een password recovery van een web-authenticatiesysteem op te zetten.

Je kan met een gebrek aan informatie niemand verwijten verkeerde aannames te hebben gedaan. Als duidelijk was dat het een intranet applicatie was dat de functionaliteit moest hebben van een password manager en daarbij ook uiteengezet wat de security van het intranet was, had je kwaliteitsreacties kunnen verwachten

De encryptie zal enkel als "laatste linie" dienen wanneer er bijvoorbeeld intern gepoogd word het systeem te kraken(niet iedere medewerker mag bij ieder wachtwoord). Ook al gaan wij hier natuurlijk niet vanuit, beter voorkomen dan genezen.

Het systeem heeft altijd een groot beveilingsissue en dat is de gebruiker van het systeem. Je kan je eigen werknemers nog zo goed vertrouwen, je zal zien dat áls het misgaat, dit vaak komt door fouten van een gebruiker.

[...]
Je baseert je antwoord op de blinde assumptie dat dit het geval is, daarbij draait dit intern. De kans op misbruik is dus vrij klein.

Op GoT wordt vaak de term glazen bol gebruikt

[...]

Dit systeem zal niet enkel gebruikt worden voor "een paar servertjes" op "neppe OSs"(?). Het gaat hier om een cluster van enkele tientallen servers draaiende op Linux, Windows, Vmware. Deze voorzien onze klanten van diverse diensten als Terminal Services, Webservices, VoIP, VPS, Mail services, Spamfilter services en meer. Daarbij worden diverse administratieve wachtwoorden hier vastgelegd (denk aan portals van leveranciers)

Aangezien het hier om een grote diversiteit aan OSs en diensten gaat is het onmogelijk om hier voor keys te gaan genereren(het gaat bijvoorbeeld ook om gebruikswachtwoorden in de AD's).

Wat betreft het niet opslaan van de key op eenzelfde lokatie heb je volledig gelijk, dit zal ook niet het geval zijn.

Ik denk ook niet dat je er vanuit moet gaat voor al deze systemen een sleutelmethode op te zetten. Je moet een nieuw systeem maken waarop deze applicatie draait, met bovengenoemde voorstellen (encryptie, sleutels, andere locatie e.d.). Dat is compleet onafhankelijk van je besturingssysteem en applicaties van alle andere diensten die je aanbied.

Op Linux desktops zijn er wallets beschikbaar voor het beheer van verschillende sleutels. Misschien is het waard daar eens naar te kijken

[Verwijderd]

Als ik eerlijk ben ben ik het met de oppositie eens, alleen om mijn eigen reden. Zolang je (de TS; Jesper P.) en je klanten het eens zijn met het feit dat de organisator in staat is in te loggen als iedere klant. Andersgezegd (realistische hypothese): Als de Admins op tweakers mijn account kunnen gebruiken, zou ik het forum nooit willen gebruiken.
Conclusie: wachtwoord-hashes zijn beter imho.
Kiek moar wat je ermee doet

[Verwijderd]

mithras schreef op dinsdag 31 maart 2009 @ 12:10:
[...]
Het was mij niet duidelijk dat het om een password manager ging. Leuk hoor, passwords te kunnen decoderen, maar 99% van de php-programmeurs doen dit om een password recovery van een web-authenticatiesysteem op te zetten.

Nee, ik snap dondersgoed dat wachtwoorden die gebruikt worden voor het inloggen op het systeem het best als hash in de database gezet kunnen worden. Met het veranderen oid van wachtwoorden ga je gewoon hashes vergelijken.

Als ik zeg dat ik een module ontwikkel waarin wachtwoorden staan die we bij klanten gebruiken (als IT dienstverlener zijnde) dacht ik dat het wel duidelijk was dat het niet om een recovery tool gaat. Misschien was ik iets te summier in m'n beschrijving, maar goed. Om me gelijk op de stapel 'typische PHP programmeur' te gooien is ook weer gelijk zoiets he

[Verwijderd]

Verwijderd schreef op dinsdag 31 maart 2009 @ 12:16:
Conclusie: wachtwoord-hashes zijn beter imho.
Kiek moar wat je ermee doet

En hoe ga jij een hash als plain text op het scherm toveren?

[Rukapul]

Verwijderd schreef op dinsdag 31 maart 2009 @ 12:06:
Wat betreft mcrypt, ik heb de code aangepast naar het volgende:

Ook heb ik al base64 encoding/decoding er over heen gedaan, maar m'n $decrypted laat op zich de goede string zien maar heeft rare tekens op het einde, 6x �. De encrypted string ziet er uit als (Ó¢§Ö¦Ÿ’/¸0&¼$J2ºw!, wat op zich goed is, al weet ik niet zeker of m'n database daar van over de zeik gaat. Edit: nee, dat gaat prima. Het gaat nu dus puur om het decrypted wat op magische wijze verkeerd gaat.

Heb je mijn reactie en de link naar Wikipedia gelezen en begrepen?

[Cartman!]

Verwijderd schreef op dinsdag 31 maart 2009 @ 12:16:
Als ik eerlijk ben ben ik het met de oppositie eens, alleen om mijn eigen reden. Zolang je (de TS; Jesper P.) en je klanten het eens zijn met het feit dat de organisator in staat is in te loggen als iedere klant. Andersgezegd (realistische hypothese): Als de Admins op tweakers mijn account kunnen gebruiken, zou ik het forum nooit willen gebruiken.
Conclusie: wachtwoord-hashes zijn beter imho.
Kiek moar wat je ermee doet

Lichtelijk offtopic hoor, maar deze forumsoftware hier ondersteunt de mogelijkheid 'imiteren' zodat een admin als t ware als jou ingelogd is Gebruiken? ja. Je wachtwoord krijgen? nee.

[Verwijderd]

Bedankt voor de toevoeging, Cartman en Jesper Ik had ook gemist dat het om een password-manager ging. Negeer mijn schrik maar Cartman legt het goed uit voor tweakers: Password-veiligheid bestaat altijd ookal is de informatiebron toegankelijk voor de admins.

[Verwijderd]

Rukapul schreef op dinsdag 31 maart 2009 @ 12:20:
[...]

Heb je mijn reactie en de link naar Wikipedia gelezen en begrepen?

Ja, maar dat zegt mij nog niet wat er mis is met het stuk code.

[Noxious]

Ach, je ontkomt er niet aan om wachtwoorden ergens op te slaan.
Bij mijn vorige werkgever stonden ze allemaal in een boekje, verstopt onder de TD-balie. Dat is natuurlijk helemaal hopeloos.

Encryptie is IMO indien goed uitgevoert de beste oplossing. Ieder domein heeft wel een paar generieke accounts voor services, installaties, backup tools, enz.
Uiteraard kun je vrijwel alles onder een eigen admin account, maar soms heb je dat soort gegevens gewoon nodig en dan ontkom je er niet aan.

Verder, bekijk deze link eens: http://www.irishwebmaster...help/7123-php-mcrypt.html

[Verwijderd]

Noxious schreef op dinsdag 31 maart 2009 @ 12:28:
Ach, je ontkomt er niet aan om wachtwoorden ergens op te slaan.
Bij mijn vorige werkgever stonden ze allemaal in een boekje, verstopt onder de TD-balie. Dat is natuurlijk helemaal hopeloos.

Encryptie is IMO indien goed uitgevoert de beste oplossing. Ieder domein heeft wel een paar generieke accounts voor services, installaties, backup tools, enz.
Uiteraard kun je vrijwel alles onder een eigen admin account, maar soms heb je dat soort gegevens gewoon nodig en dan ontkom je er niet aan.

Verder, bekijk deze link eens: http://www.irishwebmaster...help/7123-php-mcrypt.html

Held

[Noxious]

np, heeft er waarschijnlijk mee te maken dat het als een fixed lengte aan bytes uit de decryptfunctie komt en hij er spaties of tabs achter plakt.

[Rukapul]

Verwijderd schreef op dinsdag 31 maart 2009 @ 12:29:
[...]


Held

O.M.G.

Een goede oplossing bij gebruik van een blockcipher is door de lengte van de plaintext separaat bij te houden. Eventueel zijn escape sequences / specifieke padding een oplossing (zoals in dit geval de mcrypt functie default pad met '\0' wat geen geldig stringkarakter is).

Zonder enig besef gaan een stringfunctie aanroepen is echter gaar (ondanks dat het het gewenste resultaat nu geeft).

[ Voor 9% gewijzigd door Rukapul op 31-03-2009 12:45 ]

[Woy]

Verwijderd schreef op dinsdag 31 maart 2009 @ 11:18:
Het systeem in kwestie draait volledig op ons intranet, dit is een geïsoleerd netwerk wat op geen manier communiceert met het publieke netwerk. Erg vervelend dat ons aller tweaker (uitzonderingen daar gelaten) er blind vanuit gaat dat het aan beveiliging schort in plaats van een antwoord te geven op de vraag van de TS.

Ik vind het helemaal geen slechte gewoonte om ervan uit te gaan dat het aan de beveiliging schort.

Het is iets waar je gewoon over na moet denken bij het omgaan met gevoelige data. Tuurlijk hebben jullie er tijd en effort in gestoken om de beveiliging zo goed mogenlijk op orde te hebben, maar je hebt nooit 100% controle, er kan immers ook een fout in 3rd party software zitten.

Dus de eerste vraag die je jezelf moet gaan stellen is inderdaad of je de gegevens wel echt moet opslaan. In dit geval is dat blijkbaar het geval. Daarna ga je dus kijken hoe je die gegevens veilig op kan slaan. Daar is Encryptie inderdaad een goede optie voor, mits je ervoor zorgt dat een eventuele indringer zo min mogenlijk kans heeft om ook de Key te bemachtigen.

Je zou de key bijvoorbeeld kunnen afleiden van input van de gebruiker, zonder tussenkomst van de gebruiker heeft een eventuele inbreker dan nog steeds niet genoeg gegevens om de data te decrypten.

[Verwijderd]

Rukapul schreef op dinsdag 31 maart 2009 @ 12:42:
[...]

O.M.G.

Een goede oplossing bij gebruik van een blockcipher is door de lengte van de plaintext separaat bij te houden. Eventueel zijn escape sequences / specifieke padding een oplossing (zoals in dit geval de mcrypt functie default pad met '\0' wat geen geldig stringkarakter is).

Zonder enig besef gaan een stringfunctie aanroepen is echter gaar (ondanks dat het het gewenste resultaat nu geeft).

Gaar? Want?

[Woy]

Verwijderd schreef op dinsdag 31 maart 2009 @ 12:51:
[...]


Gaar? Want?

Omdat het niet slim is om zomaar iets te doen zonder dat je beseft waarom je het doet.

[NMe]

Verwijderd schreef op dinsdag 31 maart 2009 @ 12:51:
[...]

Gaar? Want?

Omdat het symptoombestrijding is in plaats van het achterliggende probleem op te lossen. Het heeft wel het effect wat je wil, maar om de verkeerde reden.

[T-MOB]

Plus dat het systeem nu faalt voor wachtwoorden die beginnen of eindigen met whitespace characters.

[Verwijderd]

Dus zoals ik het goed begrijp is het het beste om de lengte van de plain text string bij te houden en er voor zorgen dat de encrypted string niet langer wordt dan dat. Dat begreep ik uit Rukapul's post iig.

[Verwijderd]

T-MOB schreef op dinsdag 31 maart 2009 @ 13:01:
Plus dat het systeem nu faalt voor wachtwoorden die beginnen of eindigen met whitespace characters.

Dit vangen wij zoiezo af: we laten alleen alphanum characters toe, geen spaties (hoewel ik in het voorbeeld idd gebruik maakte van een wachtwoord met spaties). Maar ik zou het graag willen afvangen op encryptie niveau idd.

[NMe]

Verwijderd schreef op dinsdag 31 maart 2009 @ 13:03:
Dus zoals ik het goed begrijp is het het beste om de lengte van de plain text string bij te houden en er voor zorgen dat de encrypted string niet langer wordt dan dat. Dat begreep ik uit Rukapul's post iig.

Nee, dat begrijp je verkeerd.

Je slaat de lengte van de plaintext string op, en na de decryptie pak je de eerste <lengte> karakters van die decrypted string, en dát is dan de string die je daadwerkelijk ingevoerd hebt.

Verwijderd schreef op dinsdag 31 maart 2009 @ 13:04:
[...]

Dit vangen wij zoiezo af: we laten alleen alphanum characters toe, geen spaties (hoewel ik in het voorbeeld idd gebruik maakte van een wachtwoord met spaties). Maar ik zou het graag willen afvangen op encryptie niveau idd.

Lekker dan, wachtwoorden zijn bedoeld als veiligheid, ga je limitaties leggen op welke karakters erin voor mogen komen? Waarom zou een leesteken niet voor mogen komen in een wachtwoord? Sterker nog: een sterk wachtwoord bevat letters in lower- en uppercase, leestekens én cijfers.

[ Voor 36% gewijzigd door NMe op 31-03-2009 13:06 ]

[Noxious]

Dus:

PHP:

$output = substr($decrypted, 0, $lengte);

Lijkt me dan?

Ik ga er namelijk ook gebruik van maken, alleen niet voor wachtwoorden

[Verwijderd]

NMe schreef op dinsdag 31 maart 2009 @ 13:04:
[...]

Nee, dat begrijp je verkeerd.

Je slaat de lengte van de plaintext string op, en na de decryptie pak je de eerste <lengte> karakters van die decrypted string, en dát is dan de string die je daadwerkelijk ingevoerd hebt.

Ok, ga ik een check voor inbouwen.

Alleen hoe kan je de lengte van de plaintext het beste opslaan? Een extra kolom in je database met password_length (bv) lijkt me toch niet helemaal de bedoeling, maar zoiets moet haast wel?

[ Voor 20% gewijzigd door Verwijderd op 31-03-2009 13:11 ]

[Rukapul]

NMe schreef op dinsdag 31 maart 2009 @ 13:04:
[...]

Nee, dat begrijp je verkeerd.

Je slaat de lengte van de plaintext string op, en na de decryptie pak je de eerste <lengte> karakters van die decrypted string, en dát is dan de string die je daadwerkelijk ingevoerd hebt.

Precies.

Op zich mag een aanpak zoals nu ook wel, maar dan bewust. Dan pad je dus bewust met whitespace karakters die eraf vallen bij het trimmen. Je doet er ook verstandig aan om dit te documenteren in de sourcecode.

Zo kom je nooit in de verleiding om de code te hergebruiken om binaire data te encrypten. In dat geval zul je namelijk er niet aan ontkomen om de lengte bij te houden.

[NMe]

Verwijderd schreef op dinsdag 31 maart 2009 @ 13:09:
[...]


Ok, ga ik een check voor inbouwen.

Alleen hoe kan je de lengte van de plaintext het beste opslaan? Een extra kolom in je database met password_length (bv) lijkt me toch niet helemaal de bedoeling, maar zoiets moet haast wel?

Waarom zou dat niet de bedoeling zijn?

[Verwijderd]

NMe schreef op dinsdag 31 maart 2009 @ 13:15:
[...]

Waarom zou dat niet de bedoeling zijn?

Mwah, je geeft toch weer wat extra info weg over je wachtwoord, op database niveau. Hoewel dit waarschijnlijk niet echt kwaad kan. Vroeg me alleen af of er misschien meer gangbare methoden zijn Maar zo moet het ook lukken dan.

[Rukapul]

Verwijderd schreef op dinsdag 31 maart 2009 @ 13:17:
[...]


Mwah, je geeft toch weer wat extra info weg over je wachtwoord, op database niveau. Hoewel dit waarschijnlijk niet echt kwaad kan. Vroeg me alleen af of er misschien meer gangbare methoden zijn Maar zo moet het ook lukken dan.

Die gaf je toch al weg modulo blocksize.

De minimale wachtwoordlengte moet zodanig zijn dat het bekend zijn van de lengte geen praktisch voordeel verschaft.

[RobLemmens]

Je zou een pascal achtige string kunnen gebruiken met de lengte als eerste byte die je vervolgens behandeld als een char van je password tijdens encrypt/base64/decrypt stappen. Hoef je geen extra info in je db te hebben over het wachtwoord.

[Noxious]

mja bijv. saven als:
lengte|password
bijv.:

8|P@ssW0rd

Dan splitten op de eerste |

Dat gebruiken om de andere helft op de juiste lengte te knippen

Geen apart field en het aantal tekens is ook geen plaintext

[NMe]

Noxious schreef op dinsdag 31 maart 2009 @ 13:48:
mja bijv. saven als:
lengte|password
bijv.:

8|P@ssW0rd

Dan splitten op de eerste |

Dat gebruiken om de andere helft op de juiste lengte te knippen

Geen apart field en het aantal tekens is ook geen plaintext

Geen apart field maar het staat er dus nog steeds. Schijnveiligheid, lelijk én het negeert één van de belangrijkste principes van databases. Mooi hoor.

[Noxious]

Err, er wordt hierboven verteld dat je het in een apart field moet stoppen. Wat is het verschil dan met mijn methode behalve dat je een field minder nodig hebt?

[Woy]

NMe schreef op dinsdag 31 maart 2009 @ 13:58:
[...]

Geen apart field maar het staat er dus nog steeds. Schijnveiligheid, lelijk én het negeert één van de belangrijkste principes van databases. Mooi hoor.

Toch geef je een eventuele aanvaller minder informatie. Door de exacte lengte un-encrypted in je database te stoppen heeft de aanvaller meer informatie, en is een brute-force aanval makkelijker. Op zich haalt het in deze case niet zo heel veel uit, door de block-size weet je al aardig in welke range de lengte ligt. De lengte van je password is natuurlijk ook niet iets wat je in je database nodig hebt, aangezien je waarscijnlijk geen query gaat doen om alle passwords van 8 characters op te halen.

[NMe]

Noxious schreef op dinsdag 31 maart 2009 @ 14:00:
Err, er wordt hierboven verteld dat je het in een apart field moet stoppen. Wat is het verschil dan met mijn methode behalve dat je een field minder nodig hebt?

Zullen we dan maar het hele record in één field gaan stoppen? Da's toch ook hetzelfde?

Woy schreef op dinsdag 31 maart 2009 @ 14:03:
[...]

Toch geef je een eventuele aanvaller minder informatie. Door de exacte lengte un-encrypted in je database te stoppen heeft de aanvaller meer informatie, en is een brute-force aanval makkelijker.

Als je daar bang voor bent zou ik liever de veldnaam obfusceren dan maar twee velden te gaan truncaten voor schijnveiligheid.

[ Voor 37% gewijzigd door NMe op 31-03-2009 14:04 ]

[Cartman!]

Sla jij ook values commaseperated op ipv. via koppeltabellen dan

Waarom moeilijk doen met strings exploden als je het gewoon los kunt opslaan? Het enige voordeel wat je hebt is dat je niet plaintekst kunt uitlezen hoelang het password is van die user want om dat te weten moet je het eerst decrypten. Ik vind het erg omslachtig voor iets waar je volgens mij niet echt iets mee wint qua veiligheid.

[analog_]

Noxious schreef op dinsdag 31 maart 2009 @ 14:00:
Err, er wordt hierboven verteld dat je het in een apart field moet stoppen. Wat is het verschil dan met mijn methode behalve dat je een field minder nodig hebt?

Dat het een gore oplossing is. Je moet vervolgens met regex het uit elkaar pluizen en een veld in je DB bevat twee verschillende stukjes data. We steken toch ook niet een tabel met 15 velden in ééntje met een scheidingstekens ertussen.

[Noxious]

NMe schreef op dinsdag 31 maart 2009 @ 14:03:
[...]

Zullen we dan maar het hele record in één field gaan stoppen? Da's toch ook hetzelfde?

Lijkt me niet, ik gaf het in dit geval als voorbeeldoplossing omdat Jesper P. bang was teveel informatie weg te geven op die manier (voor het geval iemand rechtstreeks in de DB kijkt maar niet bij de code / decryptiekey kan).

Als je daar bang voor bent zou ik liever de veldnaam obfusceren dan maar twee velden te gaan truncaten voor schijnveiligheid.

Ja dat heeft lekker veel zin in een tabel met maar 2 velden
Iemand die zoiets 'hackt' heeft ook wel door dat (gezien de gebruikte techniek) het aantal tekens nog ergens staat opgeslagen, als er dan een veld 'aantal spaken in mn fietswiel' is met een aantal er in, dan geeft dat nog minder veiligheid imo.

Met mijn methode zou 'ie er vanuit kunnen gaan dat wachtwoorden overal even lang zijn, wat een aanname is die dan zn pogingen zal doen mislukken.

Verder @ regex: Wat is er mis met $output = explode("|", $input, 1);

[ Voor 44% gewijzigd door Noxious op 31-03-2009 14:08 ]

[Rukapul]

NMe schreef op dinsdag 31 maart 2009 @ 13:58:

Nou ga ik het toch niet helemaal met je eens zijn.

Geen apart field maar het staat er dus nog steeds. Schijnveiligheid

Maar wel encrypted en met de combinatie van padding tot fixed length een methode om de lengte geheel te verbergen.

, lelijk

Tja, encrypted data is nooit mooi.

Het is wel vaker gewenst dat lengtes, padding, encrypted data op hele specifieke wijze zich met elkaar verhoudt. Als je echt tijd over hebt kun je bijvoorbeeld eens kijken naar PKCS1 over hoe om te gaan met RSA encryptie. Het hangt van details aan elkaar en de schoonheidsprijs verdient het allang niet meer.

én het negeert één van de belangrijkste principes van databases. Mooi hoor.

De vraag is of die lengte wel een eigenschap is die je in de database wilt hebben. Je doet er in elk geval niets mee. Je slaat de letters van de postcode toch ook niet apart op

[Noxious]

@Rakapul: daarom dus

Op het eerste gezicht kun je er niet veel mee, maar kijk eens naar het volgende voorbeeld:

Al je wachtwoorden bij klanten zien er bijv. zo uit: "j3290fjf32f"
Een 'cracker' die met bruteforce je tabel wil gaan hax0ren die ergens mee decoded weet nooit zeker of hij dan wel een geldig resultaat heeft, hij zal dat eerst bij die klant moeten gaan proberen.

Als je het in je DB opslaat als:

code:

--------------------------
|Klant|Password   |Length|
--------------------------
|    1|j3290fjf32f|    11|
|    2|  j90f23jsd|     9|
|    3| 320-9f2j9r|    10|
--------------------------

Dan kan een aanvaller dat over meerdere tabellen checken met z'n bruteforce attack en hoeft 'ie niet de wachtwoorden IRL te gaan testen.

Sla je het op mijn manier op, dan is z'n bruteforce al een stuk lastiger, hij moet alle resultaten zelf bekijken en het idee hebben dat er iets bruikbaars tussen zit, wat hij hierboven automatisch over de hele tabel kan controleren.

[Woy]

NMe schreef op dinsdag 31 maart 2009 @ 14:03:
[...]

Zullen we dan maar het hele record in één field gaan stoppen? Da's toch ook hetzelfde?

[...]

Als je daar bang voor bent zou ik liever de veldnaam obfusceren dan maar twee velden te gaan truncaten voor schijnveiligheid.

Nee het is ( zoals hierboven ook al gezegd ) niet hetzelfde, aangezien je de waarde mee-encrypt, en dus niet leesbaar. Om de lengte te kunnen weten moet de hacker dus al de key, weten.

Als je het unencrypted voor je encrypted string zou zetten, geef ik je groot gelijk dat je het beter in een andere column kunt doen.

Een ander voordeel is dat je bijvoorbeeld ook als het password erg kort is, het alsnog kunt padden met een hoop characters zodat de attacker niet goed kan zien welke wachtwoorden het eenvoudigst te brute forcen zijn. (Anders kan je nog het een en ander afleiden van de encrypted data, maar of dat nuttig is is ook afhankelijk van de blocksize, en meestal zal die wel groter zijn dan de lengte van een password, en dus niet echt van toepassing )

Anders ga je als attacker gewoon een select op je database doen, met "order by passwordlength asc" en begin je bovenaan met brute-forcen.

[ Voor 31% gewijzigd door Woy op 31-03-2009 14:30 ]

[Verwijderd]

Ik heb het opgelost d.m.v. de password length op te slaan in een aparte kolom. Hier de code die ik gebruikt heb om het probleem op te lossen, mochten er mensen op zoek zijn naar hetzelfde:

PHP:

/**
 * Encrypts a password using mcrypt
 *
 * @param   string      Password
 * @return  string      Encrypted password
 */
public function encryptPassword($password) {
       $cipher = mcrypt_module_open(MCRYPT_BLOWFISH, '', 'cbc', '');
       mcrypt_generic_init($cipher, $GLOBALS['mcrypt']['key'], $GLOBALS['mcrypt']['iv']);
       $encryptedPassword = mcrypt_generic($cipher, $password);
       mcrypt_generic_deinit($cipher);

       return $encryptedPassword;       
}

/**
 * Decrypts a password from mcrypt encryption
 *
 * @param   string      Encrypted password
 * @return  string      Decrypted password
 */
public function decryptPassword($encrypted, $length) {
       $cipher = mcrypt_module_open(MCRYPT_BLOWFISH, '', 'cbc', '');
       mcrypt_generic_init($cipher, $GLOBALS['mcrypt']['key'], $GLOBALS['mcrypt']['iv']);
       $decryptedPassword = mdecrypt_generic($cipher, $encrypted);
       mcrypt_generic_deinit($cipher);

       return substr($decryptedPassword, 0, $length);
}

[Hydra]

Cartman! schreef op dinsdag 31 maart 2009 @ 11:53:
Ik denk dat het gewoon een gezonde discussie is en de reacties die jij als "minachtend en verwijtend" bestempt bedoeld zijn om je op weg te helpen.

Het gaat vooral om de reacties waarin gesteld wordt dat originele password opslaan, al dan niet encrypted, sowieso fout it. Soms is er gewoon geen andere oplossing. ik vind dat je best op beveiligingsimplicaties mag wijzen, maar de toon in een aantal reacties was op z'n minst betweterig te noemen.

"Imho is je model al verkeerd door aan te nemen dat het tot plain text terug te transformeren moet zijn."

Dat kan bijvoorbeeld best wat genuanceerder geformuleerd worden.

[Hydra]

Verwijderd schreef op dinsdag 31 maart 2009 @ 14:52:
Ik heb het opgelost d.m.v. de password length op te slaan in een aparte kolom. Hier de code die ik gebruikt heb om het probleem op te lossen, mochten er mensen op zoek zijn naar hetzelfde:

Waarom pad je je passwords niet zelf naar password + padding, en encrypt je die dan? Dan hoef je alleen maar een padding character te gebruiken dat niet voor mag komen in de passwords. Lage of hoge ascii characters bijvoorbeeld. Dan hoef je nergens in je database de lengte op te slaan.

[mithras]

Hydra schreef op dinsdag 31 maart 2009 @ 18:05:
[...]


Het gaat vooral om de reacties waarin gesteld wordt dat originele password opslaan, al dan niet encrypted, sowieso fout it. Soms is er gewoon geen andere oplossing. ik vind dat je best op beveiligingsimplicaties mag wijzen, maar de toon in een aantal reacties was op z'n minst betweterig te noemen.

"Imho is je model al verkeerd door aan te nemen dat het tot plain text terug te transformeren moet zijn."

Dat kan bijvoorbeeld best wat genuanceerder geformuleerd worden.

Nu zorg je er wel voor dat ik weer moet reageren

Ik heb na mijn eerste en tweede post nog een derde geschreven, heb je die ook gezien?
Ik voel met niet genoodzaakt mijn uitspraken te verantwoorden en dat ga ik ook zeker niet doen. Gezien de posts na mijn 3e reactie, zijn ook andere forumleden van deze mening gediend. Toch merk ik dat bij Jesper P. en J4zen (ben jij ook werknemer van Isaeus?) er een aversie is tegen (gegronde) kritiek en critische vragen over het systeem. Dát snap ik niet.

Daarnaast is het puur perceptie en interpretatie en denk ik niet dat er iemand (mijzelf incluis) over de schreef is gegaan . Mocht je er nog wel problemen mee hebben (of Jesper P. of J4zen), dit topic is niet de plek om het te melden imho. Verder ben ik het eens met Cartman! .

[Hydra]

mithras schreef op dinsdag 31 maart 2009 @ 19:46:
Daarnaast is het puur perceptie en interpretatie en denk ik niet dat er iemand (mijzelf incluis) over de schreef is gegaan . Mocht je er nog wel problemen mee hebben (of Jesper P. of J4zen), dit topic is niet de plek om het te melden imho. Verder ben ik het eens met Cartman! .

Ik zeg niet dat je over de schreef bent gegaan. Ik zeg dat je er bij het antwoorden op een topic als deze vanuit moet gaan dat het hashen van passwords gewoon geen optie is. Er is niks mis met iemand wijzen op de gevolgen van een dergelijke beslissing, maar in je eerste reactie zette je nogal de toon voor dit topic, en pas later nuanceerde je je reactie.

En wat betreft die nuance: "Je kan met een gebrek aan informatie niemand verwijten verkeerde aannames te hebben gedaan."

Je kunt je ook anders opstellen en in de eerste plaats proberen te achterhalen waarom passwords te achterhalen moeten zijn in plaats van ervanuit te gaan dat de TS een grote dombo is. Het is iets wat nogal veel gebeurt op dit forum en dat is gewoon een beetje jammer.

[Verwijderd]

Ik ben Debora en ik heb gelezen uw site in een heel diep en ik wil je kunnen genieten van dit schitterende inspanning. Je hebt verstrekt of ander ding zo anders dat ik niet kan dankzij woorden voor hebben.

[RobIII]

Geweldig! Thanks Ik je reply geweldig gelezen ook en schitterend genieten van inspanning die je gedaan voor post!