[JS] Clientside wachtwoorden encrypten voor in wiki

[benoni]

Je kent het wel, bij bedrijven wil het nog wel eens gebeuren dat naslag-informatie voor de alledaagse werkzaamheden is uitgewaaierd over allerlei bestandjes op verschillende servershares, al of niet beveiligd met een wachtwoord, of voor het gebruik beperkt tot een bepaald OS en/of client applicatie. Zo ook hier

Een beter alternatief dat ik nu in gebruik heb genomen, is een intranetserver met mediawiki, voorzien van wat beveiligingsniveaus (zodat iedereen makkelijk bij de gedeelde informatie kan, maar wel moet inloggen om op de specifieke informatie-pagina's te kunnen kijken).

Nu wil ik ook graag de systeembeheer-gegevens er in zetten, en daar zitten ook wat contactgegevens en wachtwoorden bij. Op zich moet dat wel kunnen ('grote' wachtwoorden zijn het niet, alleen ftp accounts en zo), maar er moeten wel meerdere bedrijven gebruik kunnen maken van dezelfde database (deels collegiaal, deels concurrerend). Daarom vind ik het niet zo'n goed idee als de bedrijfsspecifieke vertrouwelijke gegevens met één SQL-wachtwoord alsnog leesbaar zouden zijn. Ik zoek een simpel bruikbaar aanvullend encryptieniveau waarmee je blokken tekst client-side kunt coderen, zonder dat de database server daarvoor een sleutel heeft. Zo kan iedereen zelf beveiligde gegevens in de database plaatsen en kan men er van op aan dat het voor een ander redelijk onleesbaar is.

Het liefst heb ik een platform-onafhankelijke oplossing die niet geïnstalleerd hoeft te worden, een client-side Javascript oplossing zou ideaal zijn. Heeft iemand zoiets wel eens toegepast? Of weet je andere oplossingen waarmee je ook makkelijk persoonlijke en openbare informatie in één systeem kunt samenbrengen?

Javascript oplossingen:

• Herbert Hanewinkel: PGP / GnuPG / OpenPGP Message Encryption in JavaScript
  
  -> kleine foutjes in HTML, geen decryptie
• fourmilab.ch: Javascrypt
  
  -> die werkt wel lekker simpel
• ohdave.com: RSA in Javascript

Andere front ends:

• gnupg.org: Overzicht GPG front ends

[ Voor 8% gewijzigd door benoni op 07-10-2008 20:45 ]

[RobIII]

Ik ben de laatste die voor elke scheet "AJAX!!!oneone" gaat roepen, maar de JS oplossingen zijn mischien wat zwaar op een gemiddeld systeem. Wat je zou kunnen doen is een AJAX achtig iets maken waarmee je serverside de encryptie/decryptie uitvoert.

Edit: Ik heb even een proof-of-concept in elkaar geflanst: http://slash14.nl/ajax_encryption, te downloaden op http://slash14.nl/ajax_encryption.zip. Ik heb in dit geval (classic) ASP gebruikt, maar een PHP/ASP.Net/Whatever component zet je net zo makkelijk als backend er voor in de plaats.

[ Voor 42% gewijzigd door RobIII op 08-10-2008 05:28 ]

[Verwijderd]

Nadeel daarvan is wel dat de gegevens over de lijn moeten en alsnog op de gedeelde server verwerkt worden. Ze komen dan niet meer in de database terecht zonder encryptie, maar let er dus op dat de verbinding en verwerking wel goed is afgeschermd.

[RobIII]

Verwijderd schreef op woensdag 08 oktober 2008 @ 03:14:
Nadeel daarvan is wel dat de gegevens over de lijn moeten en alsnog op de gedeelde server verwerkt worden.

True; een goed afgeschermde serveromgeving en HTTPS zijn wel zo fijn dan Je zou wel het wachtwoord nog als MD5 over de lijn kunnen sturen (dat is met JS nog wel te doen) en de MD5 gebruiken als key. Dat heb ik dan ook meteen even (als optie) ingebouwd Zodoende gaat het wachtwoord nooit als clear-text over de lijn waardoor dat niet zo snel op straat zal komen liggen, maar wordt de hash dus wel gebruikt om te encrypten/decrypten i.p.v. het wachtwoord. Potato potato Het beschermt dus niet tegen sniffers; en HTTPS is sowieso aan te raden want de te encrypten en decrypted text gaat net zo goed over de lijn
Punt is dat, buiten sniffers en toegang tot het server-side component hiervan, de 'geheimen' veilig kunnen worden opgeslagen in een wiki.

[ Voor 61% gewijzigd door RobIII op 08-10-2008 05:28 ]

[benoni]

RobIII schreef op woensdag 08 oktober 2008 @ 03:20:
True; een goed afgeschermde serveromgeving en HTTPS zijn wel zo fijn dan Je zou wel het wachtwoord nog als MD5 over de lijn kunnen sturen (dat is met JS nog wel te doen) en de MD5 gebruiken als key. Dat heb ik dan ook meteen even (als optie) ingebouwd Zodoende gaat het wachtwoord nooit als clear-text over de lijn waardoor dat niet zo snel op straat zal komen liggen, maar wordt de hash dus wel gebruikt om te encrypten/decrypten i.p.v. het wachtwoord. Potato potato Het beschermt dus niet tegen sniffers; en HTTPS is sowieso aan te raden want de te encrypten en decrypted text gaat net zo goed over de lijn
Punt is dat, buiten sniffers en toegang tot het server-side component hiervan, de 'geheimen' veilig kunnen worden opgeslagen in een wiki.

Als eerste mijn dank voor de duidelijke voorbeeldscripts
Blijft dat staan voor wie later nog eens op dit topic zoekt?

Waar ik aan zit te denken: Nu stuur je het door de gebruiker ingetikte wachtwoord als MD5 hash, en de te versleutelen informatie als plain text, om dat door de server te laten encrypten. Omdat het in mijn geval maar om kleine stukjes tekst gaat, is het denk ik beter om simpelweg alle tekst meteen al client-side te encrypten. Ik heb ook een paar voorbeeldjes daarvan geprobeerd (zie de topicstart) en dat ging in een seconde. Alleen wordt in het Javascrypt voorbeeld de key pseudo-random gemaakt, dat is niet handig want dan moeten de mensen lokaal een lange key opschrijven of opslaan omdat deze niet opnieuw is te genereren met hetzelfde wachtwoord. Sowieso ziet die code om een pseudo-random key te genereren er wat rommelig uit, dus dat neem ik niet graag over. Dan liever een soort SALT die serverside wordt aangemaakt via een AJAX request (zodat decrypten in een andere omgeving niet werkt). Ik zat ook te kijken naar een rijndael implementatie in Javascript. Zou die in principe veiliger zijn?

Het lijkt me het beste dat ik van wat opensource oplossingen samen een wikimedia module ding bouw, dan kan ik dat ook weer ergens opensource aanbieden voor wie dat wil. Ik moet voor 't werk eerst nog iets anders afmaken, daarna ga ik er mee aan de slag. Qua idee moet het zoiets worden: de werking van de Wiki pagina's blijft gewoon zoals het is, maar er wordt een knop 'Versleuteling' op de pagina toegevoegd. Daarmee wordt een Javascript gestart die een wachtwoord vraagt, en daarmee alle tekstblokken die met '######' zijn afgebakend verandert in encrypted containers, of terug verandert als het al encrypted was. Eigenlijk zou er ook nog een hook in de submit-functies van het form moeten worden gehangen om het per ongeluk verzenden van gegevens in niet versleutelde staat tegen te gaan.