Paßwortabfrage mit JAVA

[Christoph Schnauß]

hallo Forum,

ich bin am Überlegen, wie ich für einen Bekannten, dessen Provider keine .htaccess zuläßt, trotzdem einen einigermaßen zuverlässigen "Zugriffsschutz" zustandebringe. Javascript scheidet aus, die Gründe sollten bekannt sein. PHP oder Perl läßt der Provider nicht zu.
Als einzigen Ausweg sehe ich, das Ganze tatsächlich mit Java (und nicht Javascript) zu probieren, indem auf der Index-Seite ein kleines Applet [1] eingefügt wird. Mich würde eure Sicht darauf interessieren. Also, wie sinnvoll so etwas sein könnte. Anderer Provider, der eben PHP oder Perl und/oder .htaccess zulassen würde, kommt für den Kumpel nicht infrage.

Grüße aus Berlin

Christoph S.

[1] Hier der Code für das Applet (ich habe das auf meinem Rechner seit zwei Jahren rumliegen, weiß aber nicht mehr, ob ich das eventuell mal irgendwo abgeschrieben habe, und wenn ja, wo). Es fehlt noch die Angabe, was eigentlich passieren soll, wenn loginname und Paßwort korrekt sind. Im Grunde genommen soll sich dann nur eine andere HTML-Seite aufrufen lassen, die eben nicht "index.*" heißt:

import java.applet.*;
import java.awt.*;
import java.awt.event.*;

public class pass extends Applet {

/** Steuerelemente für PW Eingabe definieren */
Label lbl_info = new Label("                                                  ");
Label lbl_passwort = new Label("                    Passworteingabe                    ");
Label lbl_nutzername = new Label("     Name :");
Label lbl_nutzerpw = new Label("Passwort :");
TextField txt_nutzername = new TextField();
TextField txt_nutzerpw = new TextField();
Button cmd_Ok = new Button("Ok");
ButtonListener kontrolle = new ButtonListener();

/** Steuerelemente für Inhalt definieren */
TextArea txt_MAKInfo = new TextArea(15, 35);

/** Button Listener und Passwortkontrolle */
class ButtonListener implements ActionListener
  { public void actionPerformed(ActionEvent e) {
   String passwort = txt_nutzerpw.getText();
   String loginname = txt_nutzername.getText();

if("MAK".equals(loginname))
    { if("geheim".equals(passwort)) {
       lbl_info.setVisible(false);
       lbl_passwort.setVisible(false);
       lbl_nutzername.setVisible(false);
       lbl_nutzerpw.setVisible(false);
       txt_nutzername.setVisible(false);
       txt_nutzerpw.setVisible(false);
       cmd_Ok.setVisible(false);

txt_MAKInfo.setVisible(true);
       txt_MAKInfo.setText("TEXT");
       txt_MAKInfo.setEditable(false);
      }
     else { lbl_info.setText("Loginname oder Passwort falsch!"); }
    }
   else { lbl_info.setText("Loginname oder Passwort falsch!"); }
  }
}

/** Layout und Steuerelemente initialisieren */
public void init() {
  //pass.setBackground(Color.blue);
  add(txt_MAKInfo);
   txt_MAKInfo.setVisible(false);

add(lbl_passwort);

add(lbl_nutzername);
  add(txt_nutzername);
   txt_nutzername.setColumns(25);

add(lbl_nutzerpw);
  add(txt_nutzerpw);
   txt_nutzerpw.setColumns(25);

add(cmd_Ok);
   cmd_Ok.addActionListener(kontrolle);
  add(lbl_info);
}
}

[Henryk Plötz]

Moin,

ich bin am Überlegen, wie ich für einen Bekannten, dessen Provider keine .htaccess zuläßt, trotzdem einen einigermaßen zuverlässigen "Zugriffsschutz" zustandebringe. Javascript scheidet aus, die Gründe sollten bekannt sein. PHP oder Perl läßt der Provider nicht zu.

Inwiefern soll Java da auch nur einen Funken anders machen? Java wird wie JavaScript auf dem Client ausgeführt, der Code mit dem Passwort und den evt. geschützten Inhalten ist also auf dem Client verfügbar. Noch dazu muss man bei Java üblicherweise nichtmal mit einem Hexeditor auf Spurensuche in der .class-Datei gehen, da sich diese meist einfach in eine .java dekompilieren lässt.

if("geheim".equals(passwort)) ist also auch in Java ausgemachter Unfug. Was evt. nicht vollkommen unnütz wäre, wäre das Passwort mit MD5/SHA-1 zu hashen und dann den Hash zu überprüfen, dann ist 'bloß' noch das Problem dass der Inhalt auch im .class rumliegt. Also legt man den Inhalt auf den Server und benutzt den Hash als Dateinamen. Whups, das geht ja mit JavaScript genausogut...

Wenn man einen Hauch von Sicherheit haben will müsste man schon den Inhalt verschlüsseln und aus dem Hash (mit einem Salt, versteht sich) den Schlüssel ableiten. Unter der Annahme eines nicht vollkommen beknackten Verschlüsselungsalgorithmus ist das dann nur noch über Brute Force auf das Passwort angreifbar.

Das allerdings mag mit Java in der Tat etwas schmerzfreier gehen, obwohl es mit JavaScript natürlich genauso möglich ist.

[Ludger]

Hi,

Das allerdings mag mit Java in der Tat etwas schmerzfreier gehen, obwohl es mit JavaScript natürlich genauso möglich ist.

vielen Dank fuer Deinen niveaulosen schwerzfreien Beitrag!

Allein clientseitig laesst sich keine Sicherheit, Authentifizierung und so implementieren. Sehr gut, richtig.

Gruss,
Ludger

[Daniel Thoma]

Hallo Ludger,

Was genau möchtest Du sagen?
Dass Du nicht verstanden hast, was Henryk erklärt hat?

Grüße

Daniel

[Ludger]

Hi,

Was genau möchtest Du sagen?
Dass Du nicht verstanden hast, was Henryk erklärt hat?

was hat der dann gesagt? Dass mit einer bliebigen clientseitigen Logik keine Sicherheit implementiert werden kann, oder? - Dafuer haette man aber auch meine Aushilfe zu Rate ziehen koennen: mit demselben Ergebnis

Gruss,
Ludger

[Daniel Thoma]

Hallo Ludger,

was hat der dann gesagt? Dass mit einer bliebigen clientseitigen Logik keine Sicherheit implementiert werden kann, oder? - Dafuer haette man aber auch meine Aushilfe zu Rate ziehen koennen: mit demselben Ergebnis

Ok, Du hast es tatsächlich mal wieder nicht verstanden und glaubst daher es besser zu wissen.

Er hat gesagt, dass Chrstophs Lösung nicht sicherer ist, als die entsprechende Lösung in JavaScript.
Außerdem hat er eine Möglichkeit beschrieben, wie man das sicher implementieren könnte.

Er hat wie üblich kompetent und umfassend geanwortet.
Bloß weil Du anscheinend nicht in der Lage bist, das zu erkennen, brauchst Du  nicht um Dich zu schlagen.

Ich habe kein großes Interesse daran das zu diskutieren, wollte Deinen Kommentar nur nicht so stehen lassen.

Grüße

Daniel

[Ludger]

Hi,

Außerdem hat er eine Möglichkeit beschrieben, wie man das sicher implementieren könnte.

so, welche denn?

Er hat wie üblich kompetent und umfassend geanwortet.
Bloß weil Du anscheinend nicht in der Lage bist, das zu erkennen, brauchst Du  nicht um Dich zu schlagen.

Du bist doch die arrogante Wurst, der an clientseitig generierbare Sicherheit glaubt.

Gruss,
Ludger

[Christoph Schnauß]

hallo Henryk,

Inwiefern soll Java da auch nur einen Funken anders machen? Java wird wie JavaScript auf dem Client ausgeführt

Das ist in diesem Fall richtig, kann aber nicht _pauschal_ gelten  -  wenn du an JSP denkst. Trifft _hier_ bloß nicht zu.

der Code mit dem Passwort und den evt. geschützten Inhalten ist also auf dem Client verfügbar.

Ja, aber in "verschlüsselter" (kompilierter) Form innerhalb des Applets selbst.

Noch dazu muss man bei Java üblicherweise nichtmal mit einem Hexeditor auf Spurensuche in der .class-Datei gehen, da sich diese meist einfach in eine .java dekompilieren lässt.

Es sind zwei Schritte mehr als bei einer vergleichbaren Javascript-Konstruktion.

Was evt. nicht vollkommen unnütz wäre, wäre das Passwort mit MD5/SHA-1 zu hashen und dann den Hash zu überprüfen

Hm. Danke, das ist eine Idee.

Das allerdings mag mit Java in der Tat etwas schmerzfreier gehen, obwohl es mit JavaScript natürlich genauso möglich ist.

Ich habe mir diese Aufgabe nicht selber gestellt. Es geht um einen meiner ehemaligen Mitschüler, dem ich schlecht etwas abschlagen kann  -  übrigens hoffe ich, daß er hier mitliest.

Andrerseits dachte ich, daß dieser Aspekt, sowas eben mal mit Java zu probieren, hier bisher zu selten angesprochen/diskutiert wurde. Das Meinungsbild interessiert mich schon.

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

Ich habe mir diese Aufgabe nicht selber gestellt. Es geht um einen meiner ehemaligen Mitschüler, dem ich schlecht etwas abschlagen kann  -  übrigens hoffe ich, daß er hier mitliest.

Du scheinst dich ja noch immer sehr für deine ehemaligen Mitschüler zu engagieren - immerhin hast du ja auch einer Mitschüler_in_ von dir mit ihrem Festplatten Problem geholfen, bei dem selbst du einige Zeit für die Lösung brauchtest ;-)
Da kann man nur hoffen, dass dieses Problem jetzt nicht auch so entartet *g*

Auf solche Unterstützung können deine ehemaligen Mitschüler echt froh sein :-)

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

Du scheinst dich ja noch immer sehr für deine ehemaligen Mitschüler zu engagieren

Naja, der Mann führt eine der größten und erfolgreichsten Zahnarztpraxen in Thüringen und ist zumindest teilweise dafür verantwortlich, daß ich noch ausreichend Zähne für den täglichen Einsatz zur Verfügung habe.

• immerhin hast du ja auch einer Mitschüler_in_ von dir mit ihrem Festplatten Problem geholfen, bei dem selbst du einige Zeit für die Lösung brauchtest ;-)

Ja, das war die Inspizientin des Landestheaters Eisenach, die auf ihrer uralten 80MB-Festplatte die gesamte Spielplanplanung für 2004/2005 gemacht hatte.

Da kann man nur hoffen, dass dieses Problem jetzt nicht auch so entartet *g*

Nö. Hier gehts eher noch um die Theorie. Wenn er mitliest, kann ich ihn vielleicht zu einem Providerwechsel bewegen, und dann kann ich ja mit einer serverseitigen Technik ankommen, die einigermaßen zuverlässig ist.

Auf solche Unterstützung können deine ehemaligen Mitschüler echt froh sein :-)

Hm. Das ist eine Art von "Menschelei", für die man wohl tatsächlich erstmal graue Haare bekommen haben muß. Wir haben uns teilweise (das betrifft meine gesamte ehemalige Klasse) jahrzehntelang nicht gesehen und nix voneinander gewußt. Dies Jahr machen wir ein Klassentreffen zum 35. Abitur-Jahrgang, man wird da wohl etwas nachsichtiger und schaut nach, was selbst aus denen, die man als "Mitschüler" damals nicht so recht leiden konnte, inzwischen geworden ist. Die meisten sind inzwischen glatzköpfige wohlgenährte Großväter, bloß aus mir ist halt nix Besseres als der hier geworden :-(

Grüße aus Berlin

Christoph S.

[wahsaga]

hi,

Naja, der Mann führt eine der größten und erfolgreichsten Zahnarztpraxen in Thüringen [...]
Wenn er mitliest, kann ich ihn vielleicht zu einem Providerwechsel bewegen

wäre ja auch noch schöner, wenn nicht mal ein arzt die paar kröten für ordentlichen webspace übrig hätte ...

gruß,
wahsaga

[Fabian St.]

Hi Christoph!

Naja, der Mann führt eine der größten und erfolgreichsten Zahnarztpraxen in Thüringen und ist zumindest teilweise dafür verantwortlich, daß ich noch ausreichend Zähne für den täglichen Einsatz zur Verfügung habe.

Ach, derjenige bei dem du letztens die Buchhaltung gemacht hast, oder? ;-)

Ja, das war die Inspizientin des Landestheaters Eisenach, die auf ihrer uralten 80MB-Festplatte die gesamte Spielplanplanung für 2004/2005 gemacht hatte.

Dann hatte sie ja Glück, dass du die Daten noch rekonstruieren konntest, ansonsten wäre das ja ein Haufen Arbeit geworden...

Auf solche Unterstützung können deine ehemaligen Mitschüler echt froh sein :-)

Hm. Das ist eine Art von "Menschelei", für die man wohl tatsächlich erstmal graue Haare bekommen haben muß. Wir haben uns teilweise (das betrifft meine gesamte ehemalige Klasse) jahrzehntelang nicht gesehen und nix voneinander gewußt. Dies Jahr machen wir ein Klassentreffen zum 35. Abitur-Jahrgang, man wird da wohl etwas nachsichtiger und schaut nach, was selbst aus denen, die man als "Mitschüler" damals nicht so recht leiden konnte, inzwischen geworden ist. Die meisten sind inzwischen glatzköpfige wohlgenährte Großväter, bloß aus mir ist halt nix Besseres als der hier geworden :-(

Wahrscheinlich ;-) Ich bin jedenfalls noch immer froh, wenn die Ferien anfangen und ich so ein paar Nervensägen aus meiner Klasse nicht mehr sehen muss. Übrigens Danke für den Link - die ganzen Fotos vom letzten Usertreffen habe ich noch gar nicht gesehen. Jetzt wäre bloß noch eine Zuordnung der Bilder zu den einzelnen Namen aus dem Forum hier interessant!

Grüße,
Fabian St.

[MudGuard]

Hi,

ich bin am Überlegen, wie ich für einen Bekannten, dessen Provider keine .htaccess zuläßt, trotzdem einen einigermaßen zuverlässigen "Zugriffsschutz" zustandebringe. Javascript scheidet aus, die Gründe sollten bekannt sein. PHP oder Perl läßt der Provider nicht zu.
Als einzigen Ausweg sehe ich, das Ganze tatsächlich mit Java (und nicht Javascript) zu probieren, indem auf der Index-Seite ein kleines Applet [1] eingefügt wird. Mich würde eure Sicht darauf interessieren. Also, wie sinnvoll so etwas sein könnte. Anderer Provider, der eben PHP oder Perl und/oder .htaccess zulassen würde, kommt für den Kumpel nicht infrage.

Clientseitig ist es ziemlich egal, welche Sprache Du benutzt. Es bleibt unsicher.
Mit Java ist der Aufwand, an den Code zu kommen, nur minimal höher (man muß halt das class-File dekompilieren).
Dafür hat man aber den Nachteil, daß die Anzahl der Browser mit installiertem und aktiviertem Java vermutlich deutlich niedriger ist als die mit installiertem und aktiviertem Javascript (afaik wird auf WinXP keine JavaVM mehr mitgeliefert).

cu,
Andreas

[Christoph Schnauß]

hallo Andreas,

Clientseitig ist es ziemlich egal, welche Sprache Du benutzt. Es bleibt unsicher.

ACK. Darüber sind wir uns ja im Prinzip vollkommen einig. Meine Frage geht eher dahin, ob ich von den unsicheren Methoden nicht vielleicht mit so einem Ding die "am wenigsten unsichere" bauen könnte.

Dafür hat man aber den Nachteil, daß die Anzahl der Browser mit installiertem und aktiviertem Java vermutlich deutlich niedriger ist als die mit installiertem und aktiviertem Javascript (afaik wird auf WinXP keine JavaVM mehr mitgeliefert).

Richtig. Wobei es ja jetzt so aussieht, als ob Microsoft und Sun ihre Lizenzstreitereien begraben hätten.

Mit Java ist der Aufwand, an den Code zu kommen, nur minimal höher (man muß halt das class-File dekompilieren).

Du kannst das mit dem Dekompilieren, Henryk kann das, Slyh kann das, und ich kanns natürlich auch. Und lernen kanns selbstverständlich jeder. Aber ich gehe davon aus, daß der Aufwand denn doch _ein wenig_ höher ist als bei einer Javascript-Lösung.

Theoretisch übrigens (wie in meiner Antwort an Henryk bereits angedeutet), könnte es über ein dann serverseitig appliziertes Servlet in JSP tatsächlich mit JAVA eine Alternative zu PHP/CGI und/oder .htaccess geben. Sogar mit einem ähnlichen Code, wie mein Testdings aufgeführt hat.

Das trifft allerdings für den konkreten Fall, der mich zu meiner Nachfrage veranlaßt hat, nicht zu, da wäre tatsächlich nur ein auf Clientseite ausführbares Applet denkbar. Und das Problem, daß man dafür Java implementiert haben muß, ist in diesem Fall wurscht. Der "Besitzer" der Seite hat das dann natürlich, und allein auf den kommts an (bzw. auf diejenigen, die das Paßwort kennen). Was passiert denn, wenn du kein Java aktiviert hast? Richtig, du kriegst eine ganz häßliche, korrupte Anzeige, bei der dir allerdings auch gesagt werden wird "huschhusch, verzieh dich, hier hastu eh nix zu suchen" ;-)

Grüße aus Berlin

Christoph S.

[MudGuard]

Hi,

Theoretisch übrigens (wie in meiner Antwort an Henryk bereits angedeutet), könnte es über ein dann serverseitig appliziertes Servlet in JSP tatsächlich mit JAVA eine Alternative zu PHP/CGI und/oder .htaccess geben. Sogar mit einem ähnlichen Code, wie mein Testdings aufgeführt hat.

Naja, wenn Du was serverseitiges (HTTP_AUTH per .htaccess oder irgendeine Scriptsprache) zur Verfügung hast, brauchst Du kein Applet.

Und wenn so einer "der Mann führt eine der größten und erfolgreichsten Zahnarztpraxen in Thüringen" sich nicht einen entsprechenden Webspace, der wenigstens HTTP_AUTH per .htaccess erlaubt, leisten kann, dann ist sowieso Hopfen und Malz verloren ...

Wenn's für die geschäftliche Webseite ist, kann er doch die paar Euro pro Monat auch noch steuerlich als Werbekosten geltend machen ...

Ich würd in so einem Fall nicht weiter über irgendwelche clientseitigen Murksereien nachdenken.

cu,
Andreas

[Christoph Schnauß]

hi,

Und wenn so einer "der Mann führt eine der größten und erfolgreichsten Zahnarztpraxen in Thüringen" sich nicht einen entsprechenden Webspace, der wenigstens HTTP_AUTH per .htaccess erlaubt, leisten kann

Tja. Das ist genau dieselbe Denkweise, die bei der "Gesundheitsreform" dazu geführt hat, daß Medikamnte und vieles andere derart kontingentiert wurden, daß manche Praxen bereits in der Monatsmitte keine Notfälle mehr behandeln können  -  selbst wenns ein Herzinfarkt wäre. Sie werden finanziell dafür bestraft, wenn sie den Eid des Hippokrates einhalten wollen.

Die Mediziner gehören nicht nur zu den juristisch, sondern auch zu den finanziell am schärfsten überwachten Berufsgruppen, egal, welche Fachrichtung. Jeder Opel-Mitarbeiter am Fließband hat am Monatsende deutlich mehr Geld in der Tasche (sofern sein Arbeitsplatz nicht auch auf einer der Streichlisten steht).

Ich würd in so einem Fall nicht weiter über irgendwelche clientseitigen Murksereien nachdenken.

Meine Intention bei der Fragestellung im OP war auch, daß wir bei der Debatte über "clientseitige Techniken" bisher nahezu ausschließlich an Javascript gedacht haben, aber die Frage, was denn passiert, wenn man es dann eben mal mit Java probiert, noch nicht im Detail beredet wurde.

Grüße aus Berlin

Christoph S.

[Sven Rautenberg]

Moin!

Meine Intention bei der Fragestellung im OP war auch, daß wir bei der Debatte über "clientseitige Techniken" bisher nahezu ausschließlich an Javascript gedacht haben, aber die Frage, was denn passiert, wenn man es dann eben mal mit Java probiert, noch nicht im Detail beredet wurde.

Es gab hier im Forum in der Vergangenheit bereits zwei verschiedene Links zu Seiten, bei denen man jede mögliche Spielart clientseitiger Passwortprüfung überwinden konnte - wenn man schlau genug gearbeitet hat.

Und dabei ist es im Kern garnicht mal wichtig, bei einem Algorithmus zu wissen, wie die Passwortprüfung aussieht - es reicht vollkommen, wenn man weiß, wohin nach erfolgreicher Prüfung weitergeleitet wird. :)

Insofern ist eigentlich nur ein

  
location.href = "http://www.example.org/"+document.forms[0].passwordfield.value+".html"  

erfolgreich.

• Sven Rautenberg

[Christoph Zurnieden]

Hi,

ich weiß zwar nicht, warum es einem noch nicht einmal die 10 EUR/Monat (wenn überhaupt) wert sein soll, seine Daten zumindenst ein wenig mit .htaccess zu schützen, aber gut.
Da RSA in Javascript recht anständig lahmt (zumidnest die mir bekannte Implementation) soll's also Java sein. Auch gut. Die Nachteile kennst Du ja Christoph, also wirst Du es auch versucht haben, sie Deinem Kollegen nahe zu bringen.
Aber vielleicht ist es ja auch nur die private Telephonnummer, die so geschützt werden soll o.ä., dafür würde ich wahrscheinlich auch keinen großen Aufwand betreiben wollen; so mit KK und allem umzuziehen ;-)

Du kannst am besten einen der Verschlüsselungalgorithmen hier nehmen http://www.cs.auckland.ac.nz/~pgut001/links/software.html@tile=Linkliste
(Habe nicht auf Lizenzen geprüft, müßtest Du dann selber tun, oder bei Freshmeat nachfragen)
Ist die billigste Lösung für kleinere Mengen an Daten.

NB: das eingegeben Paßwort sollte so kurz wie möglich (im Speicher) vorhanden sein. Als direkt hashen und dann _sofort_ mit Nullen (o.ä.) überschreiben! Mit ein wenig Pech und Murphys Hilfe liegt das sonst ewig und drei Tage in der Auslagerungsdatei, wird vom Käufer gefunden, der die Kiste billig bei Ebay ersteigert hat und dann zwecks Geldvermehrung zu massiver Erpressung nutzt ;-)

[1] Hier der Code für das Applet
   String passwort = txt_nutzerpw.getText();
   String loginname = txt_nutzername.getText();

Hier baust Du jetzt aus passwort+loginname den Hash und überschreibst sofort beide Strings in voller Länge(!) mit Nullen.

Ah, noch was: Es ist egal, ob der normale User Java nicht dekompilieren kann, irgendeiner kann es. Und einmal reicht im Netz, dann ist es vorbei, den Geist bekommst Du nicht mehr in die Flasche zurück. Ist hierfür wahrscheinlich alles egal, aber sollte man sich für später merken, das man es nicht selber macht oder teures Geld für jemandes Leistungen bezahlt, der sowas ignoriert.

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo Christoph ;-)

Die Nachteile kennst Du ja Christoph, also wirst Du es auch versucht haben, sie Deinem Kollegen nahe zu bringen.

Zumindest die Bedenken, die bisher in diesem Thread unter dem Sammelbegriff "clientseitig" vorgebracht wurden, sind mir hinreichend bewußt, ja.

Aber vielleicht ist es ja auch nur die private Telephonnummer, die so geschützt werden soll

Exakt. Es sind einige wenige Telefonnummern sowie Termine und Themen für Sitzungen der Zahnärztekammer, die auch von unterwegs übers neue Handy abrufbar sein sollen (das kann übrigens Java). Eingeben kann das in der Praxis die Schwester am Empfang.

Du kannst am besten einen der Verschlüsselungalgorithmen hier nehmen http://www.cs.auckland.ac.nz/~pgut001/links/software.html@tile=Linkliste

Schau ich mir mal an.

String passwort = txt_nutzerpw.getText();
   String loginname = txt_nutzername.getText();
Hier baust Du jetzt aus passwort+loginname den Hash und überschreibst sofort beide Strings in voller Länge(!) mit Nullen.

Interessanter Vorschlag. Ich probiere es mal durch.

Ah, noch was: Es ist egal, ob der normale User Java nicht dekompilieren kann, irgendeiner kann es. Und einmal reicht im Netz, dann ist es vorbei, den Geist bekommst Du nicht mehr in die Flasche zurück.

Schon klar ;-)

so short

danke erstmal.

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hi,

hallo Christoph ;-)

was soll das Grinsemännchen hinter meinem gutem Namen, he? ,-)

die auch von unterwegs übers neue Handy abrufbar sein sollen (das kann übrigens Java).

Das ist ein zeimlich gestripptes Java, das auf den Handys, würde ich sicherheitshalber vorher darauf testen. Du bräuchtest zwar nix Dolles, aber Du kennst das ja mit den Pferden und der Apotheke ;-)

Hier baust Du jetzt aus passwort+loginname den Hash und überschreibst sofort beide Strings in voller Länge(!) mit Nullen.

Interessanter Vorschlag. Ich probiere es mal durch.

Der Henryk war so nett und freundlich der Sache eine Riegel vorzuschieben. Siehe da.
Tut der Sache aber auch keinen Abbruch.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

ich weiß zwar nicht, warum es einem noch nicht einmal die 10 EUR/Monat (wenn überhaupt) wert sein soll, seine Daten zumindenst ein wenig mit .htaccess zu schützen, aber gut.

Eher Zweieurofuffzich.

[1] Hier der Code für das Applet
   String passwort = txt_nutzerpw.getText();
   String loginname = txt_nutzername.getText();

Hier baust Du jetzt aus passwort+loginname den Hash und überschreibst sofort beide Strings in voller Länge(!) mit Nullen.

Pustedingsbums, äh, kuchen. Strings sind in Java (und einigen anderen Sprachen, etwa Python) immutable, d.h. wenn du sie einmal erzeugt hast, kannst du sie nicht überschreiben um sie unbrauchbar zu machen. Und dank des nicht vorhersagbaren Verhaltens der Garbage Collection weisst du auch nicht wann der Speicher freigegeben wird (vom Überschreiben vor dem Freigeben ganz zu schweigen). Insgesamt hast du also keine Kontrolle mehr darüber ob und wann sie verschwinden. Dafür müsste dann schon ein Stringbuffer her, wobei ich mir auch da nicht sicher sein würde, dass nicht eine neunmalkluge VM mit der Meinung kommt, dass es billiger sei einen neuen leeren Stringbuffer aufzumachen anstatt den alten auszunullen.

Wobei das eh egal ist, da getText() offensichtlich einen String zurückliefert (den man wie gesagt nicht zuverlässig entsorgen kann) und daher der Geist ohnehin schon aus der Flasche ist. Und intern wird das TextField sicher auch noch den einen oder anderen String oder Stringbuffer mit dem Textinhalt rumliegen haben.

Das nur als Anmerkung damit sich hier niemand in falscher Sicherheit wiegt.

[Christoph Zurnieden]

Hi,

Hier baust Du jetzt aus passwort+loginname den Hash und überschreibst sofort beide Strings in voller Länge(!) mit Nullen.

Pustedingsbums, äh, kuchen. Strings sind in Java

Argh, ja, stimmt, verdammt.
Dabei ist das sogar bei mir auf der "Why not Java" Liste!
War wohl zu früh am Morgen für mich ,-)

Das nur als Anmerkung damit sich hier niemand in falscher Sicherheit wiegt.

Ja, danke, war wirklich nötig.

so short

Crhistoph Zurnieden