Tablets in der Schule: Bitte (fast) keine Androids mehr!

Vorweg

Ich set­ze per­sön­lich kei­ne Tablets im Unter­richt oder mei­nen eige­nen Work­flow ein. Für mich per­sön­lich sind das Spiel­zeu­ge und kei­ne Arbeits­ge­rä­te. Mei­ne Fin­ger sind zu dick und unmo­to­risch.

Ich gestal­te mei­nen digi­ta­len Unter­richt aber so, dass das Gerät dafür kaum eine Rol­le spielt, wenn es zumin­dest einen Brow­ser und eini­ger­ma­ßen per­for­man­te Leis­tungs­da­ten zum Ren­dern von Web­in­hal­ten ver­fügt. Mei­ne Tools stel­len stan­dar­di­sier­te Schnitt­stel­len bereit, sodass hof­fent­lich jeder die App und das Gerät dafür nut­zen kann, die/das zu ihr/ihm passt.

App” ist für mich ein ande­res Wort für „Pro­gramm, des­sen Ober­flä­che auf Touch­be­die­nung zuge­schnit­ten ist”. Damit sind Tablets natür­lich will­kom­men — es gibt ja ande­re Men­schen als mich mit ande­ren Vor­lie­ben und Prä­fe­ren­zen.

Was ich gar nicht mag, ist als Admin Son­der­lö­sun­gen bau­en zu müs­sen, weil ein Her­stel­ler meint, eige­ne „Stan­dards” sei­en kun­den­freund­li­cher. Des­we­gen has­se ich aus Admi­nis­tra­to­ren­sicht spe­zi­ell Apple wie die Pest. So viel zum Rant.

Was man in der Schule von der Software eines Gerätes erwarten können muss

 

  1. Regel­mä­ßi­ge Betriebs­sys­tem­up­dates
  2. Regel­mä­ßi­ge Sicher­heits­up­dates
  3. Ver­läss­li­che Sand­bo­xes für Prü­fungs­si­tua­tio­nen
  4. Ver­läss­li­ches, leicht zu bedie­nen­des MDM (Lösung zum Mana­gen der Gerä­te, wenn sie schul­ei­gen sind)

… über einen Zeit­raum von min­des­tens fünf Jah­ren. Ein Her­stel­ler, der das nicht bie­ten kann, hat nach mei­ner Mei­nung in der Schu­le bei schul­ei­ge­nen(!) Gerä­ten nichts ver­lo­ren.

Damit fal­len (fast) alle Andro­id­ge­rä­te her­aus.

Warum keine Androids?

Das Lizenz­mo­dell von Andro­id ermög­licht erst die Her­stel­lung extrem güns­ti­ger Gerä­te. Die Quell­tex­te lie­gen offen, das Sys­tem lässt sich recht unauf­wän­dig an fast jede belie­bi­ge Hard­ware­um­ge­bung anpas­sen, d.h. als Her­stel­ler bin ich in der Wahl mei­ner CPU, mei­nes Gra­fik­pro­zes­sors usw. recht frei. Dar­aus ent­steht eine Viel­zahl an Pro­dukt­li­ni­en. Um das Sys­tem per­for­mant und schlank zu hal­ten, bricht man mit einem Grund­prin­zip von Linux, auf dem Andro­id basiert: Dem gene­ri­schen Sys­tem.

Ein gene­ri­sches Sys­tem läuft unver­än­dert auf sehr vie­len unter­schied­li­chen Umge­bun­gen: Ubun­tu kann ich auf fast jeden Rech­ner instal­lie­ren — Linux bringt die dafür erfor­der­li­chen Trei­ber gleich mit und erkennt z.B. Hard­ware beim Start voll­au­to­ma­tisch.

Ein gene­ri­sches Sys­tem kann dar­über­hin­aus zen­tral geup­datet wer­den — im Prin­zip läuft ja über­all das Glei­che. Lei­der schleppt natür­lich ein gene­ri­sches Sys­tem alles nur Denk­ba­re an Trei­bern mit sich und ist daher recht groß — das passt vor allem nicht zu güns­ti­ger Hard­ware.

Kurz gesagt: Bei Andro­iden muss der Her­stel­ler jedes Sicher­heits- und Funk­ti­ons­up­dates für alle sei­ne Pro­dukt­li­ni­en manu­ell ein­pfle­gen und sei­nen Kun­den z.B. als Betriebs­sys­tem­image bereit­stel­len. Das lohnt sich bei Gerä­ten wie Tablets und Han­dys mit ohne­hin meist kur­zer Ver­wen­dungs­zeit in der Regel nicht, sprich:

Die meis­ten Andro­id­ge­rä­te sind nach recht kur­zer Zeit sicher­heits­tech­nisch ein Deba­kel

Die ein­zi­ge ech­te Aus­nah­me, die ich dies­be­züg­lich ken­ne, ist die Nexus­se­rie von Goog­le selbst. Mei­ne Nexus­ta­blets der ers­ten Gene­ra­ti­on erhal­ten bis heu­te zeit­nah Updates — schon fast vier Jah­re mitt­ler­wei­le.

Man kann aus­wei­chen auf Com­mu­nities rund um Cya­no­gen­mod — Techies wie ich könn­ten das ggf.. — aber für Schu­len im All­ge­mei­nen ist das kei­ne Opti­on.

In der Schu­le brau­che ich nach mei­nem Emp­fin­den Gerä­te, die min­des­tens drei, bes­ser fünf zuver­läs­sig lau­fen. Rea­lis­tisch fin­de ich eher einen Gerä­te­wech­sel nach drei Jah­ren, d.h. min­des­tens(!) drei Gerä­te pro Schul­lauf­bahn, denn schon heu­te wer­den die meis­ten Men­schen (auch und gera­de SuS!)  Gerä­te, die noch älter sind, auf­grund des tech­no­lo­gi­schen Wan­dels als unzu­mut­bar emp­fin­den — daher noch ein Sei­ten­hieb:

Bei Kal­ku­la­tio­nen „Tablet preis­lich gegen Schul­buch / Taschen­rech­ner / Atlas” ohne Ein­be­zug des tech­no­lo­gi­schen Wan­dels (Pro­duk­t­up­grade nach drei Jah­ren) wäre ich SEHR vor­sich­tig ob des rea­len Preis­vor­teils gegen­über heu­te — unser Wirt­schafts­sys­tem basiert nicht dar­auf, dass wir stän­dig weni­ger aus­ge­ben.

 

iPads und Windowstablets 

Apple ist ein in sich geschlos­se­nes Sys­tem und Micro­soft macht den Her­stel­lern sei­ner Gerä­te recht rigi­de Vor­ga­ben, was die Hard­ware­aus­stat­tung angeht — im Prin­zip fah­ren die die gene­ri­sche Stra­te­gie des Linux­ker­nels. Damit ist die Sicher­heits­pro­ble­ma­tik in einem wesent­li­chen Kern­punkt ent­schärft, weil nicht der Her­stel­ler Updates bereit­stellt, son­dern eben Apple und Micro­soft und die­se Updates auch über die betriebs­sys­tem­ei­ge­nen Mecha­nis­men instal­lie­ren. Die damit ver­bun­de­ne Lang­fris­tig­keit macht den Ein­satz z.B. einer MDM-Lösung oder Klas­sen­raum­steue­rung erst beherrsch­bar: Wenn ich nicht andau­ernd ver­seuch­te Gerä­te wie­der­her­stel­len und neu in eine MDM-Lösung inte­grie­ren muss, wird die Bewäl­ti­gung des Arbeits­pen­sums mög­lich. Und gera­de Schul­ge­rä­te, die durch vie­le Hän­de gehen, sind gegen­über der­ar­ti­gen Drang­sa­lie­run­gen extrem gefähr­det. Selbst Apple hat mitt­ler­wei­le kapiert, dass ein 1:1-Design eben nicht in eine 1:many-Umgebung passt und ent­wi­ckelt in die rich­ti­ge Rich­tung.

Nach­trag:

Etwas aus­führ­li­cher hat sich Andre­as Hof­mann mit der neu­en Initia­ti­ve von Apple beschäf­tigt.

 

Anfangsgenölewiederaufgriff

Mir ist völ­lig klar, dass mit der auto­ma­ti­schen Update­po­li­tik von Apple und gera­de auch Micro­soft auch sehr streit­ba­re Mecha­nis­men Ein­zug in die mobi­len Gerä­te hal­ten — vor allem vor dem Daten­schutz­hin­ter­grund. Mir wäre ein Ubun­tu-Touch auf frei­er Hard­ware ohne UEFI- und TPM-Mist bedeu­tend lie­ber.

Da wir aber im „Isnumm­al­so­land” leben, geht es um prag­ma­ti­sche Ansät­ze. Und da hat Apple schon auf­grund des App­an­ge­bot im Ver­gleich zu Micro­soft zur­zeit die Nase für vie­le Anwen­der halt vor­ne. Ich per­sön­lich fin­de das doof.

Viel­leicht fehlt es bei Andro­ids ein­fach auch nur an Dienst­leis­tern, die das Gan­ze z.B. mit Cya­no­gen­mod schlicht pro­fes­sio­na­li­sie­ren und Ser­vice­bund­les für drei bis fünf Jah­re anbie­ten.

Googles Macht (prevalence)

Goog­le hat etwas ange­kün­digt: Die Tat­sa­che, dass eine Sei­te Inhal­te auch ver­schlüs­selt per TLS ereich­bar ist, wird sich zukünf­tig posi­tiv auf das Ran­king aus­wir­ken. Auch die­ses Blog ist durch­gän­gig über https erreich­bar. Tes­ten lässt sich das für die eige­ne Home­page hier. riecken.de bekommt heu­te, am 31. Dezem­ber 2014 ein „A-”-Rating (vor­wie­gend, weil kei­ne älte­ren Refe­renz­brow­ser unter­stützt wer­den).

ssllab_2014-12-31

Die Reak­tio­nen auf Goo­g­les Vor­stoß sind unter­schied­lich.

Welche Vorteile ergeben sich dadurch?

  • ver­schlüs­sel­ter Inter­net­ver­kehr kann nicht ohne Wei­te­res mit­ge­le­sen wer­den, d.h. ein Admin wie ich hät­te — selbst wenn er es woll­te — kei­nen Zugriff auf die Inhal­te, die bei einer Inter­net­sit­zung über­tra­gen wer­den — ledig­lich die auf­ge­ru­fe­nen Sei­ten sehe ich im Log. In Fir­men- und Schul­netz­wer­ken kann man aber durch­aus trick­sen, wenn man die Kon­trol­le über die Cli­ents hat.
  • Orga­ni­sa­tio­nen, die im gro­ßen Stil Inter­net­ver­kehr mit­schnei­den wol­len, bekom­men über kurz oder lang das Pro­blem, dass immer mehr Rechen­ka­pa­zi­tät zur Ent­schlüs­se­lung not­wen­dig wird. Mas­sen­über­wa­chung wird damit also teu­rer - wenn die Ver­bin­dung durch geeig­ne­te Ein­stel­lun­gen ent­spre­chend gesi­chert ist.
  • Man erzwingt, dass Log­in- und Anmel­de­da­ten — z.B. wenn ich mich hier ein­log­ge, um einen Arti­kel zu schrei­ben — auch ver­schlüs­selt über­ge­ben wer­den. Das ist ein Sicher­heits­ge­winn.

Warum macht man das also nicht schon lange?

Das ist eine span­nen­de und gar nicht so leicht zu beant­wor­ten­de Fra­ge. Es gibt eini­ge Fall­stri­cke dabei.

1. Identität

Durch ver­schlüs­sel­te Ver­bin­dun­gen kann man ledig­lich sicher­stel­len, dass die Ver­bin­dung eben ver­schlüs­selt ist. Man weiß bei den aller­meis­ten Ver­bin­dun­gen nicht, ob man wirk­lich mit der im Zer­ti­fi­kat hin­ter­leg­ten Stel­le kom­mu­ni­ziert. Man bekommt heu­te pro­blem­los Zer­ti­fi­ka­te für Domains ohne Whois-Ein­trag — meist wird nur rudi­men­tär geprüft, ob Zugriff auf eine bestimm­te Sys­tem-E-Mail­adres­se besteht. Ledig­lich bei EV-Zer­ti­fi­ka­ten (grü­ne Adress­zei­le) kann man sich recht sicher sein, z.B. wirk­lich mit der eige­nen Bank zu spre­chen.

2. Entschlüsselung

Ich als Geheim­dienst wür­de ver­schlüs­sel­te Ver­bin­dun­gen auf­zeich­nen und dar­auf hof­fen, dass irgend­wann mei­ne Rechen­ka­pa­zi­tä­ten für eine Ent­schlüs­se­lung aus­rei­chen. Dem kann man nur ent­ge­gen­wir­ken, indem man ser­ver­sei­tig bestimm­te Ver­schlüs­se­lungs­ver­fah­ren erzwingt, z.B. Dif­fie-Hell­mann. Das geht wie­der­um oft zu Las­ten der Unter­stüt­zung älte­ren Brow­ser und Betriebs­sys­te­me. Der Kom­pro­miss bei den Ein­stel­lun­gen — gera­de bei Ban­ken — ist eben ein Kom­pro­miss.

3. Eingebettete Inhalte

Mein Brow­ser wird meckern, wenn auch einer ver­schlüs­sel­ten Web­sei­te unver­schlüs­sel­te Inhal­te nach­ge­la­den wer­den, also z.B. ein ein­ge­bet­te­tes Video von einer unver­schlüs­sel­ten Quel­le. Die­se War­nung sieht für den uner­fah­re­nen Nut­zer ziem­lich bedroh­lich aus. Er wird im Zwei­fel die­se Sei­te nicht besu­chen.

Gleich­zei­tig erschwert es genau die­ser Mecha­nis­mus z.B. Schad­pro­gram­men unent­deckt zu blei­ben — wenn sich der jewei­li­ge Ser­ver­be­trei­ber nicht die Mühe macht, ein Zer­ti­fi­kat zu besor­gen. Das Glei­che gilt aber auch für Wer­be­netz­wer­ke, die sehr oft mit ein­ge­bet­te­ten Inhal­ten arbei­ten.

Des­we­gen wird man heu­te kaum bekann­te Inter­net­por­ta­le fin­den, die über https erreich­bar sind.

4. Performance

Ver­schlüs­se­lung erfor­dert etwas mehr CPU-Power auf Sei­ten des Cli­ents und des Ser­vers. Groß­ar­ti­ge Unter­schie­de mer­ke ich bei mei­nen Last­mes­sun­gen aber nicht. Die Aus­sa­gen zum Caching­ver­hal­ten bei ver­schlüs­sel­ten Ver­bin­dun­gen sind wider­sprüch­lich. Alles in allem den­ke ich, dass die­ser Punkt ver­nach­läs­sig­bar ist.

Das sehen Fir­men, die Ange­bo­te für Bil­dungs­in­sti­tu­tio­nen machen, natur­ge­mäß oft anders. Da wird ger­ne noch die Mär von „über­flüs­sig außer beim Log­in” (immer­hin) erzählt — weil oft genug ein CDN (Con­tent-Deli­very-Net­work) im Hin­ter­grund wer­kelt und sta­ti­sche Inhal­te cached oder gar Wer­be­ban­ner nach­lädt. Das umzu­stel­len ist dann schon Auf­wand, wenn man es nach­träg­lich ange­hen muss.

5. Aufwand und Kosten

Bei Zer­ti­fi­ka­ten muss jemand bestä­ti­gen, dass mei­ne Iden­ti­tät stimmt. Das machen Zer­ti­fi­zie­rungs­stel­len, die das nach bestimm­ten Kri­te­ri­en prü­fen. Zer­ti­fi­ka­te, die jähr­lich erneu­ert wer­den müs­sen, gibt es kos­ten­los bei StartS­SL.

Die­ses Geschäfts­mo­dell ist vie­len ande­ren Händ­lern von Zer­ti­fi­ka­ten natür­lich ein Dorn im Auge — für eine pri­va­te Web­sei­te reicht ein sol­ches Zer­ti­fi­kat jedoch voll­kom­men aus. Güns­ti­ge Ein­stei­gerzer­ti­fi­ka­te gibt es ab ca. 5,- Euro pro Jahr — und die­se Zer­ti­fi­zie­rungs­stel­len prü­fen dabei nach mei­nen Erfah­run­gen auch nicht bes­ser als StartS­SL. Als Hos­ting­kun­de wird man etwas mehr anle­gen müs­sen. Gese­hen habe ich Ange­bo­te ab 15,- Euro pro Jahr — dafür hat man nichts mit Ser­ver­kon­fi­gu­ra­tio­nen zu tun.

Für Online­shops oder gar öffent­li­che Lern­platt­for­men soll­te man etwas mehr anle­gen — unter 300,- Euro pro Jahr ist da kaum etwas zu machen. Wenn mir da ein Anbie­ter ohne EV-Zer­ti­fi­kat kommt, ist das eigent­lich schon ein Aus­schluss­grund.

Ein ein­fa­ches Zer­ti­fi­kat über StartS­SL oder Como­do habe ich nach ca. fünf Minu­ten in den Hän­den und auf dem Ser­ver instal­liert. Eine EV-Vali­die­rung ist deut­lich auf­wän­di­ger. Dafür wird man einen Mit­ar­bei­ter wohl 1–2 Stun­den beschäf­ti­gen müs­sen.

Google

Goog­le nutzt eige­ne Wer­be­netz­wer­ke und kann für die­se recht pro­blem­los eine voll­stän­di­ge Ver­schlüs­se­lung ein­rich­ten. Goog­le zwingt ande­re Wer­be­netz­wer­ke jetzt qua­si dazu, es ihnen gleich­zu­tun. Wenn sich zudem höhe­re Stan­dards bei der Iden­ti­täts­va­li­die­rung durch­set­zen, wird es für Wer­be­trei­ben­de, die im Netz uner­kannt blei­ben wol­len, immer schwie­ri­ger, auch pro­mi­nent in Erschei­nung zu tre­ten — z.B. durch ein­ge­bet­te­te Ban­ner­wer­bung.

Wofür nutzt Goog­le also sei­ne Markt­macht? War­um lau­fen Ver­mark­ter gera­de Sturm gegen die­sen Vor­stoß Goo­g­les? Wie wer­den Info­por­ta­le damit umge­hen, dass sie nun Gefahr lau­fen, im Ran­king von Goog­le zu sin­ken? Han­delt Goog­le auch aus Eigen­in­ter­es­se? Oder setzt sich Goog­le hier für unse­re Sicher­heit ein?

Es ist sehr inter­es­sant, wie Goog­le hier sei­nen Ein­fluss ein­mal mehr nutzt.

In eigener Sache: riecken.de über https verfügbar

Nach einer Über­gangs­zeit von weni­gen Wochen wird riecken.de aus­schließ­lich SSL-ver­schlüs­selt abzu­ru­fen sein. Damit ist die Daten­über­tra­gung zu und von die­ser Sei­te durch einen 2048­Bit-RSA-Key gesi­chert. Der Daten­ver­kehr zwi­schen Brow­ser riecken.de ist dann nur mit gro­ßem Auf­wand abzu­hö­ren.

Die­ses Fea­ture ist pri­mär für mich wich­tig, da ich die­se Sei­te auch von öffent­li­chen Netz­wer­ken aus pfle­ge, über die ansons­ten z.B. mei­ne Log­in­da­ten im Klar­text aus­les­bar sind (mit völ­li­gen lega­len und frei ver­füg­ba­ren Netz­werk­ana­ly­se­tools wie Wire­Shark). Mich haben im letz­ten Jahr die Ana­ly­se­er­geb­nis­se von Wire­shark in ver­schie­de­nen öffent­li­chen Netz­wer­ke gera­de­zu scho­ckiert — vie­le Anwen­der sind sich des Risi­kos unge­si­cher­ter Ver­bin­dun­gen offen­bar nicht im Ansatz bewusst — dass ein Blog in frem­de Hän­de fällt, mag nicht über­aus schlimm sein, aber es wird oft genug das iden­ti­sche Pass­wort für unter­schied­li­che Diens­te genutzt.

Für die aller­meis­ten Feed­re­ader und Brow­ser dürf­te das kei­ne Anpas­sun­gen erfor­dern. Trotz­dem emp­feh­le ich, ggf, schon jetzt das Abon­ne­ment der Feed-URL von http auf https umzu­stel­len. Ich nut­ze ein kos­ten­lo­ses Ser­ver­zer­ti­fi­kat von StartS­SL, wel­ches von den meis­ten neue­ren Brow­sern und End­ge­rä­ten ohne Zer­ti­fi­kats­war­nung akzep­tiert wird. IE6.0&7.0 und sehr frü­he Andro­id­ver­sio­nen wer­den nicht unter­stützt und geben Feh­ler­mel­dun­gen aus, wel­che die Funk­ti­on der Sei­te aber nicht beein­flus­sen.

Die Instal­la­ti­on eines StartS­SL-Zer­ti­fi­kats erfor­dert Root­rech­te oder ein ent­spre­chend vor­kon­fi­gu­rier­tes Web­pa­ket und ist nicht per Plug­in zu bewerk­stel­li­gen.

Für dumm verkauft — EC-Karten

Hier ein­mal eine für mich zen­tra­le Aus­sa­ge in dem gan­zen Desas­ter:

Der der­zei­ti­ge Work­a­round, damit die Händ­ler-Ter­mi­nals die betrof­fe­nen Kar­ten wie­der akzep­tie­ren, ist nur ein Down­gra­de vom siche­ren EMV-Ver­fah­ren auf die alten, unsi­che­ren Ver­fah­ren. Dazu wer­den alle „TA-7.0”-Terminals von den jewei­li­gen Netz­be­trei­bern umkon­fi­gu­riert, damit die­se die Kar­ten nicht mehr per EMV-Anwen­dung anspre­chen, son­dern über die Anwen­dun­gen „elec­tro­nic cash ecc” oder die magnet­strei­fen­ba­sier­ten Anwen­dung „elec­tro­nic cash Spur 2” authen­ti­sie­ren. Gera­de den Magnet­strei­fen woll­te man aber mit­tel­fris­tig ablö­sen, um bei­spiels­wei­se Skim­ming-Angrif­fe abzu­weh­ren.(http://www.heise.de/security/meldung/Desaster-mit-EC-Karten-kann-teuer-werden-896988.html)

Eine gro­ße deut­sche Bank schreibt dazu in ihrer Kun­den­in­for­ma­ti­on:

Es besteht kei­ner­lei Sicher­heits­pro­blem für Ihr Kon­to und Ihre Kar­te.”

So so.Vielleicht bin ich ja doof — Ich lese aus der ers­ten Pres­se­mit­tei­lung über­setzt etwa fol­gen­des her­aus: Ihre Kar­te hat ein Schloss mit einem Sicher­heits­schlüs­sel und eines mit einem Schlüs­sel­bart. Das Schloss mit dem Sicher­heits­schlüs­sel passt nicht mehr zu gän­gi­gen Schlüs­seln, die es öff­nen sol­len, des­we­gen wird nur noch das Schloss für die Bart­schlüs­sel ver­wen­det.

Das ist für die zitier­te Bank kein Sicher­heits­pro­blem. Span­nend.

Feh­ler kön­nen über­all vor­kom­men — wobei man sich schon dar­über strei­ten kann, wie ein der­ar­ti­ger Pro­gram­mier­lap­sus sämt­li­che Kon­troll­gre­mi­en und Prüf­ver­fah­ren der deut­schen Kre­dit­wirt­schaft pas­sie­ren konn­te. Wenn ich im Unter­richt oder bei einer Klaus­ur­kor­rek­tur einen sol­chen Feh­ler mache, rude­re ich zurück und bie­ge das u.U. auf Kos­ten mei­ner Auto­ri­tät wie­der hin. Auf jeden Fall klä­re ich die Lern­grup­pe aber über die Fol­gen des Feh­lers auf. Sich hin­zu­stel­len und qua­si zu behaup­ten, alles sei wie­der abso­lut in Ord­nung emp­fin­de ich als einen Angriff auf mei­ne Intel­li­genz.

Wir brau­chen kein Wis­sen mehr. Das stört nur beim Pro­gram­mie­ren. Es ist viel­leicht wirk­lich bes­ser, wenn wir SuS mit den Kom­pe­ten­zen aus­stat­ten, sich die Lösun­gen für künf­ti­ge Pro­ble­me zusam­men­zug­o­og­len und zusam­men­zu­netz­wer­ken. Das hilft vor allen Din­gen immer dann, wenn man etwas Neu­es ent­wi­ckelt. Unglaub­lich.

Verschlüsselung in Webapplikationen (MD5)

Pass­wör­ter gehö­ren nicht in die Hän­de von Drit­ten, auch nicht in die von Admi­nis­tra­to­ren. Daher wur­den für die Spei­che­rung von Pass­wör­tern soge­nann­te Fall­tür­me­cha­nis­men (trap­door mecha­nisms) ent­wi­ckelt:

Es ist zwar mög­lich, ein Pass­wort zu ver­schlüs­seln, nicht jedoch es wie­der zu ent­schlüs­seln.

Der Ver­schlüs­se­lungs­al­go­rith­mus funk­tio­niert also genau wie eine Fall­tür nur in eine Rich­tung. Das mag auf den ers­ten Blick sinn­los erschei­nen, ist aber eigent­lich sehr pfif­fig. Neh­men wir als Bei­spiel den weit ver­brei­te­ten MD5-Algo­rith­mus. Mit die­sem sichert fast jede Web­an­wen­dung in PHP ihre Pass­wör­ter ab. Dabei wird aus

123456=> MD5-Ver­schlüs­se­ler => e10adc3949ba59abbe56e057f20f883e

Die­se lan­ge Zei­chen­ket­te sieht der Admin. Er weiß aber des­we­gen das Pass­wort im Klar­text noch nicht, da der Weg

e10adc3949ba59abbe56e057f20f883e => MD5-Ent­schlüs­se­ler (Gibt es nicht) => Pass­wort

prin­zip­be­dingt ver­sperrt ist. Die dabei ent­ste­hen­de, lan­ge Zei­chen­ket­te wird „Hash” genannt.

Wenn man sich nun an einer Web­an­wen­dung (Mood­le, Joom­la, egroup­ware …) anmel­det, macht die Web­an­wen­dung fol­gen­des:

Benut­zer gibt Pass­wort im Klar­text ein => MD5-Ver­schlüss­ler => Hash1

Die­ser Hash1 wird nun mit dem Hash — nen­nen wir ihn Hash2 — ver­gli­chen, der in der Daten­bank für den User gespei­chert ist (er könn­te etwa bei der Regis­trie­rung erzeugt wor­den sein).

Stim­men bei­den Hash­es über­ein, hat der User das kor­rek­te Pass­wort ein­ge­ge­ben, weil der Ver­schlüs­se­lungs­me­cha­nis­mus ja immer gleich ist. Stim­men die Hash­es nicht über­ein, muss der Benut­zer ein fal­sches Pass­wort ein­ge­ge­ben haben.

Soweit so gut. Das ist auch die Erklä­rung dafür, dass einen — so man sein Pass­wort ver­ges­sen hat — stets ein neu­es Pass­wort zuge­wie­sen wird, denn der Admin kann das alte Pass­wort ja nicht wis­sen, son­dern ledig­lich ein neu­es set­zen.

Eigent­lich hört sich das Gan­ze recht sicher an — ist es bloß nicht, denn es gibt Angrif­fe gegen die­ses Ver­fah­ren, die aber alle­samt vor­aus­set­zen, dass der Angrei­fer an den Hash kommt.

Wei­ter­le­sen