String verschlüsseln und mit PHP wieder entschlüsseln
Felix Riesterer
- javascript
Liebe Mitlesende,
ich hätte gerne in einer lokal abgespeicherten HTML-Datei (die nirgends online auftauchen wird) per JavaScript einen String verschlüsselt, um ihn mittels POST-Request an einen Server zu senden. Dort soll ein PHP-Script diesen wieder "auspacken" und damit etwas anfangen - falls mit dem richtigen Schlüssel verschlüsselt wurde.
Momentan nutze ich serverseitig für den umgekehrten Weg folgenden Code zur Verschlüsselung:
$encrypted = base64_encode(mcrypt_encrypt(
MCRYPT_RIJNDAEL_256,
$key,
$data,
MCRYPT_MODE_ECB
));
Um nicht-öffentliche Daten (Anzeige des Vertretungsplans) von der Schulwebsite ins Schulhaus zu übertragen, ist diese Verschlüsselung ausreichend. Der hausinterne Webserver holt sich per PHP über einen HTTP-Request (ein passender User-Agent fungiert quasi als Login-Name) diese Daten ab.
Wie kann ich nun aus dem Schulhaus heraus im Browser per JavaScript-Verschlüsselung Daten an die Website senden, damit diese keinen echten Session-basierten Login benötigt, sondern auf diese Art neue Vertretungsdaten entgegennehmen kann (Daten werden in XML-Datei gespeichert, nicht in einer DB)?
Natürlich habe ich schon nach Lösungen gesucht, bei denen man einen Text mit einer Passphrase verschlüsseln lassen kann, jedoch konnte ich diese nicht mit meinem PHP-Script korrekt entschlüsseln (Ergebnis war Zeichengemüse):
$decrypted = mcrypt_decrypt(
MCRYPT_RIJNDAEL_256,
$key,
base64_decode($encrypted),
MCRYPT_MODE_ECB
);
Welche Kombination aus JS-Bibliothek und PHP-Funktionalität könnt ihr mir für diesen Zweck empfehlen?
Liebe Grüße,
Felix Riesterer.
Liebe Mitlesende,
Teurer Felix,
lese mal genau hier:
http://code.google.com/p/crypto-js/#With_OpenSSL
Der Anker "With OpenSSL" ist kein Zufall!
Rein zufällig hatte ich das gestern schon mal wegen was anderem. Für Deinen Anwendungsfall scheint es sehr geeignet zu sein.
Also, ich habe das als BEISPIEL (so weder sicher noch bequem zu benutzen!) hinbekommen:
Sender:
<html>
<head>
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script>
function myCrypt() {
encrypted = CryptoJS.AES.encrypt(document.getElementById('data').value, "hallo");
document.getElementById('data').value=encrypted;
}
</script>
</head>
<body>
<form action="myDecrypt.php" method="post">
<textarea name="data" id="data">Foo! Bar!
Flup!</textarea><br>
<input type="button" value="verschluesseln" onclick="myCrypt()" />
<input type="submit" value="senden" />
</form>
</body>
</html>
entpacker ('myDecrypt.php'):
<?php
header('content-type:text/plain');
$file='/tmp/encrypted';
file_put_contents($file, $_POST['data']."\n");
// Da war ohne den Umbruch ein kleines Problem
print system("openssl enc -d -aes-256-cbc -a -in '/tmp/encrypted' -pass pass:hallo 2>&1")
?>
Mindestens das Passwort muss vor dem Senden in ein Formularfeld eingegeben werden, statt es hart zu codieren. Die Ausgabe ist wohl auch unerwünscht.
Ich habe mal meine obigen Einschränkungen / Verbesserungen umsetzen wollen und bin darauf gekommen, dass Googles crypto-js - Bibliothek zu openssl "nicht wirklich" kompatibel ist.
Sowas ist für mich GENAU der Grund, mich mehr auf die Basics zu verlassen und ein wenig mehr selbst zu schreiben. Ich habe lange gebraucht, um die Inkompatibilitäten - die hier Googles Fehler sind (kann aber auch an der Dokumentation von Google liegen, die den Weg des Verschlüsselns mit JS und des Entschlüsselns mit OpenSSL gerade - und warum wohl - nicht zeigt) - zu finden.
Erst einmal fehlt dem verschlüsseltem String ein Zeilenumbruch am Ende.
Dann muss die Ausgabe im konkretem Fall noch in Zeilen von maximal 76 Zeichen Länge gespalten werden. Sonst geht es nur mit kurzen Strings. Das ist natürlich erst spät aufgefallen.
Diese sind nun gelöst.
Für das Wegschreiben der decodierten Daten kann sich der interessierte Kopierer selbst was einfallen lassen. Ich gebe die für das Beispiel natürlich nur im Browser aus.
myEncrypt.html:
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script>
function myCrypt() {
pass=document.getElementById('pass').value;
encrypted = CryptoJS.AES.encrypt(document.getElementById('data').value, pass);
document.getElementById('data').value=encrypted;
document.forms[0].submit();
}
</script>
</head>
<body>
<form action="myDecrypt.php" method="post">
<textarea name="data" id="data" style="width:80%"></textarea><br>
<input type="text" id="pass"><br>
<input type="button" value="verschluesseln und senden" onclick="myCrypt()" />
</form>
</body>
</html>
Das Passwort 'ganz geheim' muss nun eingegeben werden.
myDecrypt.php:
<?php
$pass="ganz geheim";
header('content-type:text/plain;charset="UTF-8");
# Daten chunken und Zeilenbruch anhängen!
$data=chunk_split($_POST['data'])."\n";
system("echo '".$data."' | openssl enc -d -aes-256-cbc -a -pass pass:'".$pass."' 2>&1;");
Bitte die Kodierung (heißt "charset" nicht wörtlich übersetzt "Zeichensatz"?) entsprechend anpassen!
Lieber Jörg Reinholz,
vielen Dank für das neueste Beispiel! Ich werde einmal damit experimentieren.
Liebe Grüße,
Felix Riesterer.
header('content-type:text/plain;charset="UTF-8");
Nur der Vollständigkeit halber, da fehlt vor der schliessenden Klammer ein '
Probier das Beispiel grad mal aus, interessiert mich, die Thematik :)
header('content-type:text/plain;charset="UTF-8");
Nur der Vollständigkeit halber, da fehlt vor der schliessenden Klammer ein '
Ja, da ist was falsch. Das charset="UTF-8" hatte ich hier nachgetragen, auf meinem Rechner muss ich das nicht machen (Regel in der Apache-Konfiguration).
Ich sitze derzeit am Lappi, das die Telefonleitung getört ist (Monteur kommt hoffentlich am Montag), damit DSL nicht geht und hatte vorhin um in der Wohnung richtig mobil zu sein, das kleine angeworfen.
header('[link:http://www.w3.org/International/O-HTTP-charset.de.php#charset@title=Content-Type: text/plain; charset=utf-8]');
Jörg Reinholz
Hab grad mal ein wenig gelesen. In den User Contributed Notes zu openssl gibts ne Klasse, die kommt ohne Aufruf mit system() aus.
http://php.net/manual/en/function.openssl-decrypt.php
Habs getestet und klappt. Openssl muss natürlich in PHP aktiviert sein, ist aber zumindest bei Squeeze und Wheezy standardmässig aktiviert.
echo sqAES::decrypt($pass, $_REQUEST['data']);
class sqAES {
/**
* decrypt AES 256
*
* @param string $password
* @param data $edata
* @return dencrypted data
*/
public static function decrypt($password, $edata) {
$data = base64_decode($edata);
$salt = substr($data, 8, 8);
$ct = substr($data, 16);
/**
* From https://github.com/mdp/gibberish-aes
*
* Number of rounds depends on the size of the AES in use
* 3 rounds for 256
* 2 rounds for the key, 1 for the IV
* 2 rounds for 128
* 1 round for the key, 1 round for the IV
* 3 rounds for 192 since it's not evenly divided by 128 bits
*/
$rounds = 3;
$data00 = $password.$salt;
$md5_hash = array();
$md5_hash[0] = md5($data00, true);
$result = $md5_hash[0];
for ($i = 1; $i < $rounds; $i++) {
$md5_hash[$i] = md5($md5_hash[$i - 1].$data00, true);
$result .= $md5_hash[$i];
}
$key = substr($result, 0, 32);
$iv = substr($result, 32,16);
return openssl_decrypt($ct, 'aes-256-cbc', $key, true, $iv);
}
/**
* crypt AES 256
*
* @param string $password
* @param data $data
* @return base64 encrypted data
*/
public static function crypt($password, $data) {
// Set a random salt
$salt = openssl_random_pseudo_bytes(8);
$salted = '';
$dx = '';
// Salt the key(32) and iv(16) = 48
while (strlen($salted) < 48) {
$dx = md5($dx.$password.$salt, true);
$salted .= $dx;
}
$key = substr($salted, 0, 32);
$iv = substr($salted, 32,16);
$encrypted_data = openssl_encrypt($data, 'aes-256-cbc', $key, true, $iv);
return base64_encode('Salted__' . $salt . $encrypted_data);
}
}
Habs getestet und klappt.
Bevor ich das jetzt (nochmal) mache frage ich erst mal: Kann das auch ganz konkret die Daten entschlüsseln, die mit der besprochenen Google-Bibliothek in Javascript verschlüsselt wurden?
Das wäre vorliegend wichtig.
Jörg Reinholz
Habs getestet und klappt.
Bevor ich das jetzt (nochmal) mache frage ich erst mal: Kann das auch ganz konkret die Daten entschlüsseln, die mit der besprochenen Google-Bibliothek in Javascript verschlüsselt wurden?
Ich habs mit deinem Beispiel verschlüsselt und mit der geposteten Klasse entschlüsselt, als klappt es.
Ob es mit komplexen Texten und Passwörtern klappt, hab ich nicht getestet, aber mit dem Text "das ist ein test" und dem PW "xxx" hats einwandfrei funktioniert.
Da ich grad versuche, meine Mysql-Replikation aus SSL umzustellen, ist meine Testzeit im Moment begrenzt :)
Lieber M., lieber Jörg,
Habs getestet und klappt.
hab's mit einer HTML-Datei getestet, welche korrekt wieder entschlüsselt werden konnte. Offensichtlich ist das die von mir gesuchte Lösung.
Ich habs mit deinem Beispiel verschlüsselt und mit der geposteten Klasse entschlüsselt, als klappt es.
Auch ich habe mit Jörgs Code erfolgreich testen können (unter Verwendung der "sqAES"-Klasse).
Ob es mit komplexen Texten und Passwörtern klappt, hab ich nicht getestet, aber mit dem Text "das ist ein test" und dem PW "xxx" hats einwandfrei funktioniert.
Hier mein Testaufbau (Datei "endecrypt.php"):
<?php
$key = '1337 "$%&/ üöäß';
?>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>En-/DeCrypt</title>
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script type="text/javascript">
function myCrypt() {
pass = '<?php echo $key ?>';
encrypted = CryptoJS.AES.encrypt(
document.getElementById('data').value,
pass
);
document.getElementById('data').value = encrypted;
document.forms[0].submit();
}
</script>
</head>
<body>
<?php
function decrypt($password, $edata) {
$data = base64_decode($edata);
$salt = substr($data, 8, 8);
$ct = substr($data, 16);
$rounds = 3;
$data00 = $password.$salt;
$md5_hash = array();
$md5_hash[0] = md5($data00, true);
$result = $md5_hash[0];
for ($i = 1; $i < $rounds; $i++) {
$md5_hash[$i] = md5($md5_hash[$i - 1].$data00, true);
$result .= $md5_hash[$i];
}
$key = substr($result, 0, 32);
$iv = substr($result, 32,16);
return openssl_decrypt($ct, 'aes-256-cbc', $key, true, $iv);
}
if (array_key_exists('data', $_POST)) {
printf (
"<pre>decrypting...\r\n%s</pre>\r\n",
htmlspecialchars(
decrypt($key, $_POST['data'])
)
);
}
?>
<form action="" method="post">
<textarea name="data" id="data" style="display:block;height:450px;width:800px;">
<?php
echo htmlspecialchars(
file_get_contents('./index.html')
);
?>
</textarea>
<input type="button" value="verschluesseln und senden" onclick="myCrypt()" />
</form>
</body>
</html>
HERZLICHSTEN DANK!!!
Liebe Grüße,
Felix Riesterer.
Hallo Ingrid,
jetzt wollte ich anstatt das Formular abzuschicken einen XMLHttpRequest machen:
ajax = null;
try {
// Mozilla, Opera, Safari sowie Internet Explorer (ab v7)
ajax = new XMLHttpRequest();
} catch(e) {
try {
// MS Internet Explorer (ab v6)
ajax = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e) {
try {
// MS Internet Explorer (ab v5)
ajax = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
ajax = null;
}
}
}
if (ajax) {
update = CryptoJS.AES.encrypt(
update,
'mein geheimes passwort'
);
ajax.open(
"POST",
"http://localhost/test.php",
true
);
ajax.setRequestHeader(
"Content-Type",
"application/x-www-form-urlencoded;charset=utf-8"
);
ajax.send("data=" + encodeURIComponent(update));
}
Mit debug-Ausgaben konnte ich überprüfen, dass exakt der String in $_POST['data'] steht, den ich auch in der Firebug-Konsole zu sehen bekomme. Aber warum wird nun die Entschlüsselung nicht vorgenommen? Passwort ist sowohl im JS als auch im PHP-Script korrekt eingetragen!
Wer sieht etwas, das ich übersehen habe?
Liebe Grüße,
Felix Riesterer.
Ach Ingrid...
das Verhältnis von Wald und Bäumen verursacht manchmal, dass man die Reihenfolge von Funktionsargumenten verwechselt. Wer also die Daten als Passwort deklariert, braucht sich nicht zu wundern, wenn das Passwort nicht korrekt in unverschlüsselte Daten zurück entschlüsselt wird. m( *fazialpalmier*
Gute Nacht und liebe Grüße,
Felix Riesterer.
Hallo Felix-Ingrid,
*fazialpalmier*
heidenei! Ich habe zwar genug Fremdwortkenntnisse, um diesen Ausdruck auf Anhieb zu verstehen - aber gehört oder gelesen habe ich das vorher noch nicht. Sind solche Wortkreationen bei dir üblich? ;-)
Ebenfalls gute Nacht,
Martin
Lieber Martin,
*fazialpalmier*
heidenei! [...] Sind solche Wortkreationen bei dir üblich? ;-)
musste da meinen Namensvetter zitieren.
Liebe Grüße,
Felix Riesterer.
Hallo Ingrid,
vielleicht sollte ich noch hinzufügen, dass wenn man eine in ISO-8859-1 kodierte Textdatei via AJAX "laden" will, diese grundsätzlich als UTF-8 interpretiert erhält.
Als ich meine Textdatei in xhr.responseText vorliegen hatte, habe ich diesen Inhalt in eine <textarea> geschrieben und bei den üblichen Verdächtigen (deutsche Umlaute und das ß) wirre Zeichen erhalten. Die Inhalte in ISO-8859-1 wurden von JS als UTF-8 gedeutet.
Um das zu lösen, muss man versuchen, die Zeichenkodierung mittels xhr.overrideMimeType()
"reparieren". In meinem Beispiel war das so:
var xhr = myCreateXmlHttpRequestObject();
xhr.open("GET", "./verz/file.txt", true);
// wahrscheinlich wirkungslos, [link:http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method@title=weil W3C das so will]
xhr.setRequestHeader("accept", "text/plain; charset=iso-8859-1");
// Zeichenkodierung nicht automatisch als UTF-8, sondern als ISO-8859-1 interpretieren
if (xhr.overrideMimeType) { // Firefox / Safari
xhr.overrideMimeType("text/plain; charset=iso-8859-1");
}
xhr.send(null);
Vielleicht erspart das jemandem Stunden der Fehlersuche...
Liebe Grüße,
Felix Riesterer.
Lieber Jörg Reinholz,
print system("openssl enc -d -aes-256-cbc -a -in '/tmp/encrypted' -pass pass:hallo 2>&1")
sehe ich das richtig, dass ich einen system-Call benutzen muss, oder wäre auch eine andere Funktion "im Lieferumfang von PHP" möglich (z.B. mcrypt_decrypt)?
Mindestens das Passwort muss vor dem Senden in ein Formularfeld eingegeben werden, statt es hart zu codieren. Die Ausgabe ist wohl auch unerwünscht.
Bitte vergiss nicht, dass es eine lokal abgespeicherte HTML-Datei sein wird, in der alles "hart kodiert" sein darf. Wichtig ist nur, dass ein verschlüsselter Datensatz an die Website gePOSTed wird, den diese dann wieder entschlüsseln soll. Das Passwort ist sowohl dem PHP-Script, als auch der HTML-Datei "bekannt", wird aber selbst logischerweise nicht übertragen.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
Bitte vergiss nicht, dass es eine lokal abgespeicherte HTML-Datei sein wird, in der alles "hart kodiert" sein darf.
Das konnte ich gar nicht vergessen, das war mir zu dem Zeitpunkt noch nicht bekannt. Ich habe es geschrieben, damit nicht ein unbedarfter Kopierer einen hübschen Bypass implementiert und sich dann wundert, dass die Staatsanwaltschaft ihn informiert, dass seine Kundendatenbank mit den Kreditkartennummern in den einschlägigen Foren wie Sauerbier angeboten wird.
Übrigens...
Du kannst:
print system("openssl enc -d -aes-256-cbc -a -in '/tmp/encrypted' -pass pass:hallo 2>&1");
auch umbauen.
<?php
header('content-type:text/plain');
$pass="hallo";
$tempfile=tempnam('/tmp', 'PHP_');
$data=chunk_split($_POST['data'])."\n";
$str=exec("echo '".$data."' | openssl enc -d -aes-256-cbc -a -pass pass:'".$pass."' > $tempfile 2> /dev/null;echo $?");
if ('0'==$str) {
echo "Das hat geklappt:\n-------------------------------\n", file_get_contents($tempfile), "\n-------------------------------\n";
unlink($tempfile);
} else {
unlink($tempfile);
echo "Fehler!";
}
Ist dann nämlich das Passwort falsch schmeisst openssl einen Fehler der in $? steht. Das lässt sich so auswerten.
Die Daten stehen vor dem Löschen in $tempfile bereit...
Teurer Felix,
:-)
Teuerster Jörg,
herzlichsten Dank für Deine erschöpfenden Untersuchungen! Ich habe alle Deine Postings in diesem Thread gelesen und werde an Ort und Stelle dazu antworten.
Liebe Grüße,
Felix Riesterer.
Hi,
ich hätte gerne in einer lokal abgespeicherten HTML-Datei (die nirgends online auftauchen wird) per JavaScript einen String verschlüsselt, um ihn mittels POST-Request an einen Server zu senden.
Warum "von Hand" verschlüsselt/entschlüsselt?
Was spricht gegen die Verwendung von https?
cu,
Andreas
Lieber MudGuard,
Was spricht gegen die Verwendung von https?
aus meiner Sicht ist das eine andere Baustelle. Jeder Client kann doch eine Verbindung zu der Schulwebsite aufbauen, egal ob HTTP oder HTTPS. Wenn dann Daten im Klartext gepostet werden (vorausgesetzt, man kennt das Format), dann könnte jeder "nicht authorisierte" Besucher auf der Website neue Vertretungsstunden (oder Stundenausfälle) einstellen. Um das zu verhindern, bräuchte es einen echten sessionbasierten Login-Mechanismus (sowas kann ich), der es erfordert, dass man sich am CMS anmeldet, bevor man neue Vertretungsdaten einstellt.
Nun ist es aber so, dass die Vertretungen über ein passendes Formular in einer lokal abgepseicherten HTML-Datei (mit sehr viel JavaScript) sowohl zu Papier gebracht, als auch auf die Website gestellt werden sollen. Diese Lösung erspart es mir, eine Desktop-Anwendung für irgendein Windoof zu schreiben, die sich dann auch noch mit den verschärften Netzwerkbeschränkungen des Verwaltungsnetzes herumschlagen müsste. Also nutze ich bereits vorhandene Standardsoftware (Firefox), um zu erreichen, was ich will.
Um aber nun den Login-Vorgang zu vermeiden, brauche ich einen Ersatz, der es ebenso nur einem "authorisierten Besucher" erlaubt, neue Daten einzupflegen, wie es ein Login-basierter Mechanismus erlauben könnte. Damit fielen ein paar Mausklicks und Tastatureingaben weg und die Handhabung der eigentlichen Aufgabe des Users würde etwas vereinfacht werden.
Nochmals: Statt echtem Login will ich verschlüsselte Daten schicken, deren Verschlüsselung den Login-Mechanismus ersetzen soll.
Glaubst Du wirklich HTTPS alleine wäre eine vollständige Lösung meines Problems? Aus meiner Sicht bietet es nur eine zusätzliche Schicht an Sicherheit, weil bei der Datenübertragung niemand den verschlüsselten Datensatz mitlesen kann, um an die Art der Verschlüsselung und das verwendete "Passwort" zu kommen, um nun seinerseits Daten zu POSTen.
Oder habe ich Deinen Hinweis missverstanden?
Liebe Grüße,
Felix Riesterer.
Nun ist es aber so, dass die Vertretungen über ein passendes Formular in einer lokal abgepseicherten HTML-Datei (mit sehr viel JavaScript) sowohl zu Papier gebracht, als auch auf die Website gestellt werden sollen.
Aber wieso soll er sich dann - schon für den Erhalt des Formulars - nicht ganz normal anmelden? Was, wenn sich herausstellt, dass openssl Probleme macht?
Jörg Reinholz
Lieber Jörg Reinholz,
Aber wieso soll er sich dann - schon für den Erhalt des Formulars - nicht ganz normal anmelden?
das Formular hat er bereits im Browser, da er eine entsprechende HTML-Datei von seinem Desktop lokal im Browser geöffnet hat. Er soll sofort loslegen können, ohne sich jedes Mal auf der Website anzumelden. Falls im Ernstfall kein Internet-Zugang verfügbar wäre, soll zumindest der Ausdruck auf Papier möglich sein!
Was, wenn sich herausstellt, dass openssl Probleme macht?
Ich habe mich noch nicht um SSL auf unserer Schulwebsite gekümmert. Daher kann ich Dir in Sachen verschlüsselter Verbindung noch keine sinnvollen Angaben machen.
Vielleicht sollte ich mir lieber über eine JS-gesteuerte automatische Anmeldung im Hintergrund (z.B. AJAX) Gedanken machen? Dann wäre eine Übertragung der Daten mittels POST innerhalb einer session-basierten Anmeldung möglich... Bisher dachte ich jedenfalls, ich könnte ein JS-Pendant zu mcrypt_encode/mcrypt_decode finden und einfach Sachen mit JS "eintüten" und auf der anderen Seite mit PHP auspacken. Passt der Schlüssel nicht zum Auspacken, werden die Daten wieder verworfen. Aber wenn so schwierig zu verstehen ist, was ich _tatsächlich_ will und mir immer etwas von SSL angeboten wird, dann ist das vielleicht tatsächlich der falsche Ansatz...?
Liebe Grüße,
Felix Riesterer.
Hallo felix,
Aber wenn so schwierig zu verstehen ist, was ich _tatsächlich_ will und mir immer etwas von SSL angeboten wird, dann ist das vielleicht tatsächlich der falsche Ansatz...?
Naja... ich hab schon verstanden, was Du willst.
Du verteilst die HTML-Datei.
Die wird lokal geöffnet und die Lehrer können fummeln.
Beim Absenden wird ein Passwort genommen und die Datei verschlüsselt.
Wenn das Passwort nicht stimmt wird auch nicht entschlüsselt.
Das ist zwar ein wenig "von hinten durch die Brust ins Auge" - aber ok. Die Datei mit dem hart codierten Passwort ist dann der Ausweis. (und nach Möglichkeit auch gleich das Zeichen, dass die aktuelle Version benutzt wurde...)
Beachte für Deinen Spezialfall bitte auch diese Änderungen/Erweiterungen.
Ob PHP mit eingebauten Funktionen das auch entpacken kann muss ich übrigens erst nachschauen. Aber openssl gibt es auf jedem Linux-Rechner. Es ist essentiell.
Jörg Reinholz
Lieber Jörg Reinholz,
Naja... ich hab schon verstanden, was Du willst.
Du verteilst die HTML-Datei.
richtig.
Die wird lokal geöffnet und die Lehrer können fummeln.
Richtig - wobei das selbstverständlich ausgewählte Personen mit entsprechenden Befugnissen und Aufgaben sind.
Beim Absenden wird ein Passwort genommen und die Datei verschlüsselt.
"Datei" ist etwas viel gesagt, lediglich ein paar Parameter werden als POST-Request abgesetzt, wobei ich diesen Request gerne als verschlüsseltes Datenpaket umgesetzt hätte - insofern kannst Du gerne "Datei" dazu sagen.
Wenn das Passwort nicht stimmt wird auch nicht entschlüsselt.
Das ist zwar ein wenig "von hinten durch die Brust ins Auge" - aber ok.
Dieses Vorgehen ist einigen widrigen Umständen geschuldet, die zum einen in den besonderen Restriktionen unseres Netzwerkes liegen (HTTP(S) ist möglich, wenn man den Proxy mit passenden Login-Daten füttert), zum anderen aber in einer sehr... (*Anwalt für Formulierung fragen*) ... eigenwilligen Software-Ausstattung unserer Verwaltung begründet ist.
Die Datei mit dem hart codierten Passwort ist dann der Ausweis. (und nach Möglichkeit auch gleich das Zeichen, dass die aktuelle Version benutzt wurde...)
Kann man so sagen. Es werden nur Daten zu einer bestimmten Abweichung vom Stundenplan versandt, die online in der XML-Datei "zu den anderen" hinzugefügt wird.
Beachte für Deinen Spezialfall bitte auch diese Änderungen/Erweiterungen.
Ich habe noch immer nicht eingesehen, welche Relevanz openssl für mein Anliegen hat. Soll openssl lediglich die Verschlüsselung als solche durchführen, oder geht es um eine SSL-verschlüsselte Verbindung über HTTPS?
Ob PHP mit eingebauten Funktionen das auch entpacken kann muss ich übrigens erst nachschauen. Aber openssl gibt es auf jedem Linux-Rechner. Es ist essentiell.
Scheint so, als wolltest Du openssl die Verschlüsselung vornehmen lassen, ohne unbedingt eine SSL-verschlüsselte HTTP-Verbindung zu nutzen... Mal schauen.
Liebe Grüße,
Felix Riesterer.
Hi,
Du verteilst die HTML-Datei.
Die wird lokal geöffnet und die Lehrer können fummeln.Richtig - wobei das selbstverständlich ausgewählte Personen mit entsprechenden Befugnissen und Aufgaben sind.
Und wenn der Lehrer die Schule wechselt, in Rente geht, aus dem Schuldienst entfernt wird ...
Löschst Du dann die Datei wieder von seinem Rechner?
cu,
Andreas
Und wenn der Lehrer die Schule wechselt, in Rente geht, aus dem Schuldienst entfernt wird ...
Löschst Du dann die Datei wieder von seinem Rechner?
Muss er nicht. Er muss dem Nachfolger nur eine neue Version mit einem neuen Passwort geben und natürlich auch im PHP-Skript ändern.
Das kann man (halb-)automatisch erzeugen.
Jörg Reinholz
Hi,
Und wenn der Lehrer die Schule wechselt, in Rente geht, aus dem Schuldienst entfernt wird ...
Löschst Du dann die Datei wieder von seinem Rechner?Muss er nicht. Er muss dem Nachfolger nur eine neue Version mit einem neuen Passwort geben und natürlich auch im PHP-Skript ändern.
Es reicht aber nicht, dem Nachfolger ein neues Passwort zu geben.
Wenn, dann müssen alle berechtigten PCs mit neuer HTML-Datei (inkl. neuem Passwort) versehen werden. Denn wenn das alte Passwort noch gültig bliebe (für die anderen User, die nicht der Nachfolger des ausgeschiedenen Lehrers sind), könnte der ausgeschiedene ja immer noch zugreifen.
Halte ich nicht wirklich für praktikabel.
cu,
Andreas
Halte ich nicht wirklich für praktikabel.
Ich habe da auch meine bedenken. Aber Felix hat sein Ansinnen in einer Weise und mit anderen Einschränkungen begründet, die ich für nachvollziehbar halte.
Scheinbar erscheint ihm der Aufwand vertretbar.
Aber ich hoffe, er wird nie einen Nachfolger einarbeiten müssen...
Jörg Reinholz
Lieber MudGuard,
Und wenn der Lehrer die Schule wechselt, in Rente geht, aus dem Schuldienst entfernt wird ...
Löschst Du dann die Datei wieder von seinem Rechner?
LOL!!! Das kann nur jemand fragen, der nicht im Schuldienst von Ba-Wü ist.
Wenn Du glaubst, bei uns hätte jede Lehrkraft ihren eigenen Rechner, dann muss ich Dich aufklären: Dem ist nicht so.
Wenn Du weißt, wer in einer Schule alles am Vertretungsplan schrauben darf, dann wirst Du schnell sehen, dass diejenigen sich den dafür benutzten Rechner teilen. Es genügt also allen Ernstes, dass da eine einzige HTML-Datei auf diesem Rechner herumliegt.
Außerdem kann ich das benötigte Passwort zur Verschlüsselung jederzeit online ändern (in einer Konfigurationsmaske), um es an den passenden Stellen anzupassen (hausinterner Webserver). Die HTML-Datei lasse ich mir dann online wieder zusammenbauen (jetzt mit dem neuen Passwort) und speichere sie wieder lokal - ein Vorgang den ich nach jedem Stundenplan-Update ohnehin tun muss, denn diese lokale HTML-Datei enthält das Wissen um aktuell gültige Stundenpläne, den Klarnamen aller Lehrkräfte samt ihrer Kürzel, um Falscheingaben zu vermeiden.
Liebe Grüße,
Felix Riesterer.
Hi,
Das kann nur jemand fragen, der nicht im Schuldienst von Ba-Wü ist.
Bin ich zugegebenermaßen beides nicht - weder im Schuldienst, noch in Ba-Wü.
Hierzulande (BY) wird bei Schülern die Existenz eines PCs inkl. Internet-Zugangs praktisch vorausgesetzt (Hausaufgaben a la "Sucht dazu mal was in der Wikipedia")
Daß die Lehrer möglicherweise keinen von der Schule/Schulbehörde/... zur Verfügung gestellten Rechner haben, mag ja sein. Aber ein Lehrer heutzutage ohne Computer?
Davon, daß nur von Dir handverlesene Rechner im Spiel sind, hast Du bisher nirgends erwähnt.
Ist denn sichergestellt, daß die Lehrer die Datei nicht einfach auf ihren privaten PC kopieren können und von dort aus nutzen?
Wenn Du glaubst, bei uns hätte jede Lehrkraft ihren eigenen Rechner, dann muss ich Dich aufklären: Dem ist nicht so.
Außerdem kann ich das benötigte Passwort zur Verschlüsselung jederzeit online ändern (in einer Konfigurationsmaske), um es an den passenden Stellen anzupassen (hausinterner Webserver). Die HTML-Datei lasse ich mir dann online wieder zusammenbauen (jetzt mit dem neuen Passwort) und speichere sie wieder lokal - ein Vorgang den ich nach jedem Stundenplan-Update ohnehin tun muss, denn diese lokale HTML-Datei enthält das Wissen um aktuell gültige Stundenpläne, den Klarnamen aller Lehrkräfte samt ihrer Kürzel, um Falscheingaben zu vermeiden.
D.h. nach jeder Änderung mußt Du an allen berechtigten Rechnern rumfummeln?
Erscheint mir ein sehr durchdachtes Konzept zu sein ...
cu,
Andreas
Lieber MudGuard,
Hierzulande (BY) wird bei Schülern die Existenz eines PCs inkl. Internet-Zugangs praktisch vorausgesetzt (Hausaufgaben a la "Sucht dazu mal was in der Wikipedia")
ob das zulässig ist, mag die entsprechende Behörde entscheiden (Benachteiligung sozial schwächer Gestellter ...).
Daß die Lehrer möglicherweise keinen von der Schule/Schulbehörde/... zur Verfügung gestellten Rechner haben, mag ja sein. Aber ein Lehrer heutzutage ohne Computer?
Was hat der eigene PC zuhause mit einem Dienst-Gerät in der Schule zu tun? Und was "ein Lehrer" tut ist nicht dasselbe, was ein Mitglied der Schulleitung tut!
Davon, daß nur von Dir handverlesene Rechner im Spiel sind, hast Du bisher nirgends erwähnt.
Ich suche auch im Wesentlichen eine technische Lösung für ein technisches Problem, welches ich hoffentlich hinreichend beschrieben habe (str in JS verschlüsseln und in PHP wieder entschlüsseln).
Ist denn sichergestellt, daß die Lehrer die Datei nicht einfach auf ihren privaten PC kopieren können und von dort aus nutzen?
Wir reden hier von Verantwortungsträgern. Wenn von denen einer Mist baut, dann muss es dieser entsprechend auch verantworten. Wenn einfach Schüler nicht zur entsprechenden Schulstunde erscheinen, weil jemand etwas Kreatives in den Vertretungsplan online gehackt hat, dann geht davon erstens die Welt nicht unter und entsteht zweitens auch kein direkter monetärer Schaden.
Außerdem reden wir hier von exakt einer (1) Datei auf exakt einem (1) Rechner - was hinsichtlich meiner Fragestellung im Grunde auch irrelevant ist.
D.h. nach jeder Änderung mußt Du an allen berechtigten Rechnern rumfummeln?
Erscheint mir ein sehr durchdachtes Konzept zu sein ...
Bei einem Passwortwechsel ist an genau einem Rechner (hausinterner Server) und dem Webserver selbiges anzupassen. Nach einem geänderten Stundenplan muss dieser auf die Website exportiert werden, um danach die eine HTML-Datei auf dem einen Rechner upzudaten.
Ob das ein durchdachtes Konzept ist, mag man tatsächlich bezweifeln, jedoch ist es das momentan einzig praktisch mögliche. Eine Ideallösung ist zur Zeit aus politischen und ... weiteren ... Gründen undurchführbar.
Es ist ja schön, dass Du Dir Gedanken um das generelle Konzept machst, jedoch wäre mir bei der Erörterung der konkreten technischen Aufgabenstellung mehr geholfen!
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
Bei einem Passwortwechsel ist an genau einem Rechner (hausinterner Server) und dem Webserver selbiges anzupassen. Nach einem geänderten Stundenplan muss dieser auf die Website exportiert werden, um danach die eine HTML-Datei auf dem einen Rechner upzudaten.
ich versuche mir gerade eure IT-Infrastruktur vorzustellen. So wie ich es bisher verstehe, habt ihr einen "hausinternen Server", an dem sich per lokalem Login auch ausgewählte Personen direkt anmelden können, um aktuelle Daten zu pflegen, sowie einen Webserver, der außerhalb der Schule steht.
Warum das? Wenn da sowieso schon ein lokaler Server rennt, dann wäre es das Natürlichste, wenn der auch den Webauftritt und das Intranet der Schule hostet. Dann wäre alles auf einer Maschine.
Es ist ja schön, dass Du Dir Gedanken um das generelle Konzept machst, jedoch wäre mir bei der Erörterung der konkreten technischen Aufgabenstellung mehr geholfen!
Ja, sicher. Aber auch mir kommt die Basis, die dir zur Verfügung steht, ziemlich hanebüchen vor. Meine Güte, warum nicht ein hausinterner Server, der irgendwo in einem Rechnerraum vergraben steht, und dazu ein überschaubarer Personenkreis, der dort per SSH, FTP oder Samba-Freigabe auf "wichtige" Verzeichnisse zugreifen darf - und das sowohl von einem (gemeinsam genutzten?) PC im Sekretariat, als auch vom privaten PC zuhause?
Mit verständnislosem Kopfschütteln
Martin
Lieber Martin,
ich versuche mir gerade eure IT-Infrastruktur vorzustellen.
ohje... ;-)
So wie ich es bisher verstehe, habt ihr einen "hausinternen Server", an dem sich per lokalem Login auch ausgewählte Personen direkt anmelden können, um aktuelle Daten zu pflegen,
Nein. Der hausinterne Server dient einzig und allein der Archivierung und Verwaltung von hausinternen Anzeigeflächen (wie den verlinkten Vertretungsmonitor). Nebenbei bietet er noch Routing von einem Subnetz ins Schülernetz, damit wir Kiosk-PCs in der Schülerbücherei anbieten können.
An diesem hausinternen Webserver kann nur ich mich als Admin anmelden, um per SSH nach dem Rechten zu sehen.
sowie einen Webserver, der außerhalb der Schule steht.
Wir sprechen von einem "shared hosting"-Paket, welches unsere Schulwebsite hostet. Das steht irgendwo im Internet auf einem Server in einem deutschen Rechenzentrum auf deutschem Boden.
Warum das? Wenn da sowieso schon ein lokaler Server rennt, dann wäre es das Natürlichste, wenn der auch den Webauftritt und das Intranet der Schule hostet. Dann wäre alles auf einer Maschine.
Und mit welcher Datenanbindung soll das geschehen? Eine reguläre kommerzielle DSL-Leitung? Nein. Der Schulträger hier hat noch andere Schulen zu tragen und löst das Problem der Datenanbindung über ein größeres Klasse-A-Netz, welches er auf Novell-Basis in voneinander getrennte Netze unterteilt. Das Ordnungsamt sollte unsere Rechner nicht per Ping erreichen können - und umgekehrt wir dessen Rechner auch nicht. Aber damit alle ein einigermaßen zügig reagierendes Internet haben, welches zentral "zensiert" werden kann, werden sechs DSL-Leitungen nach draußen gebündelt, so dass nach meinem Verständnis von "physikalischer Trennung" spätestens hier die Netze aneinander stoßen müssten... o_O
Kommst Du noch mit, beim Dir-vorstellen unserer IT-Infrastruktur? Ja? Herzlichen Glückwunsch!
Warum genügt es eigentlich nicht, wenn ich (zugegeben, nicht im eröffnenden Posting) schreibe, dass HTTP(S)-Traffic über einen Proxy mittels Login-Daten möglich sei, ansonsten aber nichts!? Mir ist die fürchterlich vermurkste Ausgangslage schmerzlichst(!!!!!!!!einselfhundertelftausendundeins!!!!) bewusst. Wie schön wäre es, wenn ich auf meinem privat mitgebrachten Laptop "einfach" Linux-Pakete nachinstallieren könnte, oder per FTP auf unseren Webspace zugreifen dürfte. Nein, das scheitert alles - nur wenn ich eine MAC-Adresse eines Schulrechners spoofe, dann kann ich einen zweiten Proxy nutzen, der mich das alles machen lässt (hierzu verkneifst Du Dir jetzt bitte jegliche weitere Anschlussfrage!).
Aber auch mir kommt die Basis, die dir zur Verfügung steht, ziemlich hanebüchen vor.
Sind wir jetzt seelenverwandt? Naja, aufgrund der unterschiedlichen Herkunft obiger Einsicht vielleicht doch noch nicht... ;-)
Meine Güte, warum nicht ein hausinterner Server, der irgendwo in einem Rechnerraum vergraben steht, und dazu ein überschaubarer Personenkreis, der dort per SSH, FTP oder Samba-Freigabe auf "wichtige" Verzeichnisse zugreifen darf - und das sowohl von einem (gemeinsam genutzten?) PC im Sekretariat, als auch vom privaten PC zuhause?
Du kennst die Verpflichtung der Schulen nicht, KISS zu nutzen. Du kennst die Rechtslage nicht genügend um zu verstehen, dass die Schülerdaten in einem Netz liegen müssen, welches physikalisch von dem Netz getrennt sein muss, in dem sich Schüler aufhalten können. Deswegen haben wir an der Schule zwei getrennte Netzwerke: 1-Schülernetz, 2-Verwaltungsnetz. In beiden Netzen gibt es eigene Benutzer und Home-Verzeichnisse, jedoch ist kein Rechner des einen Netzes aus dem anderen erreichbar und umgekehrt. Um nun Daten von einem Rechner aus dem einen Netz ins andere zu transferieren muss(!) ein externer Datenträger (z.B. Stick) benutzt werden. Die IT-Abteilung der Stadt hat sich das vom Land extra zertifizieren lassen müssen.
Das hat natürlich zur Folge, dass Mitglieder der Schulverwaltung zwei Zugänge haben, einen für jedes Netz.
Mit verständnislosem Kopfschütteln
Das ist eine völlig normale Reaktion auf das Zusammentreffen von Schulverwaltung und EDV-/IT-Welt. Meine Halswirbel sind dementsprechend bedenklich abgenutzt. :-(
Liebe Grüße,
Felix Riesterer.
Hi Felix,
ich versuche mir gerade eure IT-Infrastruktur vorzustellen.
ohje... ;-)
ja, das dachte ich auf halber Strecke auch schon.
sowie einen Webserver, der außerhalb der Schule steht.
Wir sprechen von einem "shared hosting"-Paket, welches unsere Schulwebsite hostet. Das steht irgendwo im Internet auf einem Server in einem deutschen Rechenzentrum auf deutschem Boden.
So hatte ich mir das auch vorgestellt.
Warum das? Wenn da sowieso schon ein lokaler Server rennt, dann wäre es das Natürlichste, wenn der auch den Webauftritt und das Intranet der Schule hostet. Dann wäre alles auf einer Maschine.
Und mit welcher Datenanbindung soll das geschehen? Eine reguläre kommerzielle DSL-Leitung?
Ich dachte da eher an eine professionelle Anbindung, bei der die Upstream-Bandbreite (Downstream aus User-Sicht) mindestens so groß, besser größer ist als die Downstream-Bandbreite.
Nein. Der Schulträger hier hat noch andere Schulen zu tragen und löst das Problem der Datenanbindung über ein größeres Klasse-A-Netz, ...
Die Schule kann hier also nicht eigenverantwortlich agieren? Sch... ähm, schade.
welches er auf Novell-Basis in voneinander getrennte Netze unterteilt.
Autsch. Novell. Noch'n Geschwür.
Das Ordnungsamt sollte unsere Rechner nicht per Ping erreichen können - und umgekehrt wir dessen Rechner auch nicht.
Hä?? Was soll das denn?
Kommst Du noch mit, beim Dir-vorstellen unserer IT-Infrastruktur? Ja? Herzlichen Glückwunsch!
Ja, so ungefähr, aber nicht in allen Einzelheiten.
Aber auch mir kommt die Basis, die dir zur Verfügung steht, ziemlich hanebüchen vor.
Sind wir jetzt seelenverwandt? Naja, aufgrund der unterschiedlichen Herkunft obiger Einsicht vielleicht doch noch nicht... ;-)
Man kann auch bei unterschiedlichen Ansätzen zur gleichen Schlussfolgerung kommen. ;-)
Du kennst die Verpflichtung der Schulen nicht, KISS zu nutzen.
Gerade das KISS-Prinzip wäre doch ein Grund, etwas in der Art zu implementieren, wie ich es skizziert habe.
Du kennst die Rechtslage nicht genügend um zu verstehen, dass die Schülerdaten in einem Netz liegen müssen, welches physikalisch von dem Netz getrennt sein muss, in dem sich Schüler aufhalten können.
Nicht konkret, aber das leuchtet mir ein, das hätte ich erwartet. Deswegen gehe ich ja auch davon aus, dass zwischen dem schulinternen Intranet und dem öffentlich erreichbaren Internet keine direkte Verbindung besteht - das ist ja in vielen Industriebetrieben nicht anders.
Mit verständnislosem Kopfschütteln
Das ist eine völlig normale Reaktion auf das Zusammentreffen von Schulverwaltung und EDV-/IT-Welt. Meine Halswirbel sind dementsprechend bedenklich abgenutzt. :-(
Mein herzliches Beinkleid,
Martin
Hallo Felix,
Ich habe noch immer nicht eingesehen, welche Relevanz openssl für mein Anliegen hat.
OpenSSL sorgt in dem Fall für die Entschlüsselung. Es ist quasi das Original, genauer ein wrapper der die eigentlichen Algorithmen benutzbar macht (sogar mitbringt) und auf jedem Linux, BSD, Solaris zur Verfügung steht und auf Windows / Apfelrechnern installiert werden kann...
Soll openssl lediglich die Verschlüsselung als solche durchführen, oder geht es um eine SSL-verschlüsselte Verbindung über HTTPS?
Nein. Nur die Daten aus der Textarea werden in Javascript durch die Google-Bibliothek verschlüsselt und übertragen, dann auf dem Server mit openSSL entschlüsselt. KEIN HTTPS.
Scheint so, als wolltest Du openssl die Verschlüsselung vornehmen lassen, ohne unbedingt eine SSL-verschlüsselte HTTP-Verbindung zu nutzen... Mal schauen.
Das war doch Dein Anliegen? Aber nochmal: Die Daten aus der Textarea werden in Javascript durch die Google-Bibliothek verschlüsselt, auf dem Server mit openSSL entschlüsselt.
Jörg Reinholz
Om nah hoo pez nyeetz, Felix Riesterer!
ich hätte gerne in einer lokal abgespeicherten HTML-Datei (die nirgends online auftauchen wird) per JavaScript einen String verschlüsselt, um ihn mittels POST-Request an einen Server zu senden. Dort soll ein PHP-Script diesen wieder "auspacken" und damit etwas anfangen - falls mit dem richtigen Schlüssel verschlüsselt wurde.
Dieser String ist der Vertretungsplan?
Dieser String ist der komplette Inhalt der XML-Datei?
Der Vertetungsplan ist für jeden Tag eine eigene XML-Datei?
wäre dann nicht der direkte upload per FTP/SSH eine Alternative?
Das Vertretungsplanscript sammelt dann die verschiedenen XML-Dateien ein, bringt sie zur Anzeige bzw. archiviert sie für die Statistik.
Matthias
Lieber Matthias Apsel,
Dieser String ist der Vertretungsplan?
ja.
Dieser String ist der komplette Inhalt der XML-Datei?
Nein. Er ist ein komplettes HTML-Dokument für die Anzeige auf unserem hausinternen Monitor. Diese HTML-Datei wird von einem hausinternen Webserver von der Website geladen und archiviert. Das geschieht bei Bedarf, wenn nämlich eine Anzeigetafel eine solche Datei anzeigen will.
Der Monitor selbst holt sich die Seite nach jedem Durchlauf (es wird in 12-Sekunden-Intervallen "gescrollt") die Seite erneut vom hausinternen Server, der wiederum prüft, ob er die alte Seite noch einmal ausgibt, oder ob diese bereits das Haltbarkeitsdatum überschritten hat und er eine neue Seite von der Website holt.
Auf dem hausinternen Server läuft ein Script, welches anhand der IP-Adresse des anfragenden Clients eine entsprechende "Anzeige" ausliefert - damit mehrere Anzeigen verwaltet werden können, gerne auch mit verschiedenen Inhalten (Vertretungsplan oder Infotafel mit Veranstaltungsterminen, Ankündigungen, Eilmeldungen etc.). Die dafür benötigten HTML-Dateien kommen schon fix&fertig von der Website - aber eben verschlüsselt, da sie "personenbezogene Daten" beinhalten (im Wesentlichen sind das die vollständigen Nachnamen der Lehrkräfte im Vertretungsplan).
Der Vertetungsplan ist für jeden Tag eine eigene XML-Datei?
Nein, die XML-Datei wird bei jedem "Füttern" neu gespeichert, wobei "veraltete" Einträge (bis einschließlich vom Vortag) herausgefiltert werden.
wäre dann nicht der direkte upload per FTP/SSH eine Alternative?
Nein, das erlaubt das extrem restriktive Netzwerk in unserer Schule nicht. HTTP(S) mit einem Client ist möglich, wenn dem Proxy-Server passende Login-Daten gegeben werden. FTP und SSH "nach draußen" sind Dinge der Unmöglichkeit.
Das Vertretungsplanscript sammelt dann die verschiedenen XML-Dateien ein, bringt sie zur Anzeige bzw. archiviert sie für die Statistik.
Nö, das habe ich anders gelöst (s.o.).
Liebe Grüße,
Felix Riesterer.