My password is"S3cr3t" by yeprWe zijn gewend aan veilige communicatie: als we mobiel bellen sturen we een signaal de ether in en we gaan er van uit, dat niet iedereen zomaar mee kan luisteren. Bij een bankoverschrijving typen we onze toegangsgegevens in in een webpagina en we vertrouwen er op, dat niet iemand anders die gegevens zomaar kan gebruiken om geld van je rekening af te halen. In beide voorbeelden wordt de informatie niet zondermeer de ether of cyberspace in gestuurd: er vindt eerst een versleuteling plaats. Zelfs als je de bankoverschrijving vanaf een zonnig vakantie-terrasje met "wifi libre" doet, gaat dat goed. Er staat https:// voor de URL en je ziet in de statusbalk het slotje. Dit is beveiligd, dit is een SSL-verbinding, met een officieel "certificaat". Voor de zekerheid kijk je nog even of de URL wel klopt, maar verder vertrouw je het wel.

En dat geeft ook weinig problemen in de praktijk. Je bent er zo aan gewend dat alles beveiligd is, dat je er soms niet meer op let of dat misschien ergens niet het geval is. Sommige providers geven bijvoorbeeld geen beveiligde toegang voor webmail of klanten-inlog. Op zich niet zo'n probleem, maar niet geschikt om te gebruiken op een openbaar wifi-netwerk. Hetzelfde geldt voor de administrator-inlog van Joomla!; en voor heel veel andere web-applicaties (waaronder Drupal en WordPress).

Dus: pas op als je even je blog bij wil werken vanaf je vakantieadres. Of even in wil loggen op je Joomla!-site vanuit een bar.

Sniffing

Als je geen beveiligde verbinding hebt, worden bij Joomla! het gebruikersnaam en wachtwoord die je op een inlog-formulier intypt gewoon als "platte tekst" doorgegeven. Het hele HTTP-POST-pakketje wordt het netwerk opgestuurd met een geadresseerde erbij vermeld. Ieder knooppunt in het netwerk kijkt of het misschien voor haar/hem bedoeld is en stuurt het eventueel door. Bij een Wifi-netwerk wordt het betreffende pakketje aan alle computers in dat netwerk aangeboden. Normaal kijkt de computer waar het pakketje niet voor bedoeld is niet verder naar dat pakketje. Met behulp van vrij verkrijgbare programmatuur kun je dat netwerk-verkeer echter volledig bekijken. Dat is dus inclusief alle informatie die in het pakketje zit. Tenminste: wanneer die gegevens niet versleuteld zijn. "Sniffers" heten zulke programma's. Een heel bekende is WireShark. Op "J and Beyond" had ik er eentje draaien en het is reuze interessant om te zien wat er allemaal voorbijkomt... Ook flink schrikken, hoe simpel het is dat anderen je toegangsgegevens kunnen bekijken.

SSL

Als je de inlog van een Joomla!-site veilig wil maken is SSL (Secure Socket Layer) de beste methode: dan staat er bovenin https:// en onderaan komt dat slotje. Om dat te doen moet je een certificaat kopen en een beveiligde toegang maken. Je provider kan je er ongetwijfeld meer over vertellen. Iedere gebruiker die op die site inlogt doet dat dan via die beveiligde verbinding. Het versleutelen gebeurt met een zogenaamde public key: daarmee kan iedereen de informatie versleutelen. Het ontcijferen kan alleen met een zogenaamde private key en die blijft op de server. Je kunt een public key vergelijken met een open hangslot: iedereen kan het gebruiken om iets mee af te sluiten (door het slotje dicht te klikken), maar het openen van het slotje kan alleen met de sleutel (de private key).

SSL heeft echter 2 nadelen: ten eerste kan het niet bij iedere shared hosting provider en ten tweede zijn er, soms aanzienlijke, kosten aan verbonden. De kosten van het kopen van een certificaat zijn meestal een veelvoud van de kosten van hosting. Geen enkel probleem dus als je een wat groter bedrijf hebt of met een stevige e-commerce-applicatie te maken hebt, maar voor huis-tuin-en-keuken-gebruik een beetje uit verhouding.

Voor privé-gebruik kun je eventueel zelf een certificaat aanmaken, maar vanuit de browser krijg je dan allerlei nare meldingen dat het een niet te vertrouwen site zou zijn; dit zou eventueel nog een optie kunnen zijn als je een site waar je de enige gebruiker van bent, wil beveiligen met een certificaat, maar verder is dit niet echt werkbaar.

Nieuw: een encryptie-extensie voor Joomla!-login

Er is echter sinds kort een heel handige extensie, waarmee de inlog op bijna dezelfde manier versleuteld kan worden als met SSL gebeurt: de Encryption Configuration extensie van Ratmil Torres. Deze plugin versleutelt de login ook met een public key (om precies te zijn: met RSA). Daarvoor moet op de server wel de bcmath-library draaien (standaard vanaf PHP 4.0.4); die is nodig om met grote gehele getallen te kunnen werken. Mocht dat onverhoeds niet op je server aanwezig zijn, dan wordt teruggevallen op het simpeler DES; niet ideaal, maar alles beter dan helemaal geen versleuteling.

De extensie is geheel gratis, kersvers in het Nederlands vertaald door ons eigen taalteam op joomlacommunity.nl en is hier te downloaden of van http://www.ratmilwebsolutions.com/downloads/encryption-configuration.html. Vergeet niet een review te schrijven en een stem uit te brengen op de JED; volgens mij verdient Ratmil een heel groot applaus voor deze extensie.

Blijf alert!

Deze versleuteling van wachtwoorden is een goede bescherming tegen het ongewenst stelen van je wachtwoord op openbare netwerken. Maar daarnaast is het als gebruiker nog steeds oppassen met je wachtwoorden bij een Joomla!-site: aan de administrator-kant worden alle wachtwoorden eerst weer naar "platte tekst" omgezet en pas daarna vergeleken met het wachtwoord dat in de database of elders zit. Iemand met toegang tot de backend kan dus in pricipe altijd de wachtwoorden vastleggen van iedereen die inlogt. Dat geldt ook, wanneer je bijvoorbeeld met je GMail-account inlogt (een mogelijkheid die in de core-distributie van Joomla! zit). We werken nog aan een veiliger inlog. Technisch: door met een Ajax-call de "salt" bij een bepaalde gebruiker van de server te halen en ondermeer daarmee het wachtwoord te versleutelen. Maar hoe goed je een beveiliging ook maakt, het blijft ook altijd een kwestie van vertrouwen wanneer je ergens inlogt.

Gebruik dus niet op allerlei sites eenzelfde wachtwoord en pas ook op met het inloggen op een site met je Twitter-account, je GMail-gegevens en dergelijke. Ondertussen kun je komende zomer echter wel veilig op de site(s) inloggen die je wil beheren vanaf je vakantievereblijf: door Ratmil's extensie te installeren. Ik ga 'm voortaan standaard op al mijn Joomla!-sites gebruiken.

5 reacties

EasyDiscuss Avatar
pjdevries
Zeer nuttig. Dank je wel Herman.
EasyDiscuss Avatar
jmkleijn
Goed werk, bedankt Herman.
EasyDiscuss Avatar
Jmu
Beste Herman,<br /><br />Leesbaar en duidelijk stuk. Bedankt.<br />Nog wel een vraag: je ziet na installeren niets van de plug-in; hoe weet je nou of die ook werkt?<br />Andere vraag (misschien een beetje dom, maar ik heb me nog niet verdiept in de achtergronden): je ziet in de broncode wel de key staan. Is dat geen probleem?<br /><br />Joop
EasyDiscuss Avatar
Marie-Anne Melis
Voorzover ik heb kunnen zien kan zien, krijg je als je b.v. inlogt op de administrator tussen het moment dat je het wachtwoord hebt bevestigd en het laden van de nieuwe pagina dat er nog een x-aantal bullets achter het wachtwoord worden geplaatst.<br /><br />thnx Herman!
EasyDiscuss Avatar
Herman Peeren
Antwoord op de vragen van Joop:<br /><br />1. "je ziet na installeren niets van de plug-in; hoe weet je nou of die ook werkt?". <br /><br />Inderdaad zie je nu alleen maar, zoals Tigi ook opmerkte, eventjes dat er meer wachtwoord-bullets bij komen. De schrijver van de extensie (Ratmil Torres) is er echter mee bezig om in een volgende editie achter het versleutelde veld een icoontje (een slotje) te zetten om aan te geven dat het veld versleuteld wordt. Hij had dat al voor deze editie (1.1.7) af willen hebben, maar dat is niet gelukt. Natuurlijk kun je zelf even Wireshark draaien (http://www.wireshark.org/download.html) en zoeken naar de betreffende HTTP POST regel; dan zie je dat inderdaad de boel netjes versleuteld is. Heel leerzaam om ook eens te zien hoe het er uit ziet als het onversleuteld langskomt.<br /><br />Zoiets dergelijks staat er onversleuteld:<br />POST /administrator/index.php HTTP/1.1<br />Host: www.jouwdomeinnaam.eu<br />[nog wat regels, waaronder het cookie]<br />username=jouwgebruikersn aam&passwd=jouwwachtwoord&lang=&option=com_login&task=login&[token, hexadecimaal]=1<br /><br />Met versleuteling is die laatste regel met username en passwd zoiets geworden: <br />login_form-login0_formtoke n=ujkvsbitlkvlciw w&encrypted_p asswd_modlgn_pa sswd0=[een lange hexadecimale string]&username=jouwgebruikersn aam&passwd=[30 sterretjes]&enz. <br />Er zijn dus een aantal velden bijgekomen, waaronder het versleutelde wachtwoord en het oude wachtwoord is vervangen door sterretjes. Je zou eventueel zelfs de gebruikersnaam ook kunnen laten vervangen. Je kunt bij dit component namelijk zelf opgeven welke velden je versleuteld wilt hebben.<br /><br />2. "je ziet in de broncode wel de key staan. Is dat geen probleem? "<br /><br />Zijn natuurlijk nooit domme vragen! De sleutel die je in de broncode ziet staan is de "public key". Daarmee is het wachtwoord alleen te versleutelen, niet te ontcijferen. Die RSA-versleuteling gebeurt altijd met behulp van 2 bij elkaar horende sleutels: een public en een private key. Die public key kun je naar iedereen sturen: daarmee kun je alleen maar iets versleutelen. De private key blijft op de server. Die wordt gebruikt om de boel weer te ontcijferen. Mooi principe, hè, die public en private key.<br /><br />Op zich is er nog meer mogelijk met die private en public key (bijvoorbeeld iets met de private key versleutelen en met de public key ontcijferen), maar dat is bij deze extensie verder niet gebruikt. SSL maakt van die exra mogelijkheden wel gebruik. Het mooie van SSL is wel, dat het versleutelings-algoritme dan in de browser verwerkt zit en dat gaat sneller dan via javascript. De sleutel moet je ook niet te groot maken bij deze extensie, want dan moet je lang wachten op de versleuteling en ontcijfering. Bij mij duurde het bij een 512-bits sleutel ongeveer 0,25 seconden, bij een 1024-bits sleutel bijna 2 seconden en bij een 2048-bits sleutel zelfs zo'n 15 seconden (onwerkbaar dus). Ik zag cijfers van RSA met OpenSSL en die waren ongeveer een factor 1000 lager. DSA is dan nog eens 2x zo snel als RSA. Er is dus wellicht nog wat te verbeteren aan deze extensie. Maar goed: het is alleen maar voor de inlog en dan is een kwart seconden wachten nog wel te doen.

Reageer

1000 Resterende tekens