nicht angemeldet dedlfix
Matthias Apsel
Der Martin
Gunnar Bittersmann
Matthias Apsel
dedlfix
Matthias Apsel
Der Martin
Gunnar Bittersmann
Matthias Apsel
Hallo,
ich bin gerade dabei, den Administrationsbereich unserer Bandhomepage zu erstellen.
Zunächst wird geprüft, ob bereits ein Fingerabdruck vom Client erstellt wurde. Wenn nicht, dann wir er erstellt und die Seite aus der Datei "Fingerprint.js" heraus neu aufgerufen. Wenn ja, dann wird geprüft, ob bereits eine Aktion übergeben wurde. Wenn nicht, dann wird das Anmeldeformular angezeigt, das die Aktion "Anmelden" festlegt.
Und genau hier liegt mein Problem.
Es wird nach dem Absenden des Anmeldeformulars immer wieder nur das Anmeldeformular angezeigt, der $_POST["Aktion"]-Variable scheint keinerlei Beachtung geschenkt zu werden.
Nachfolgend der reduzierte Code, den ich hier leider nicht im Multihighlighter-Format formatieren kann:
<?php
if (!isset ($_POST["Fingerprint"]))
{
?>
<!DOCTYPE html>
<html>
<head><script type="text/javascript" language="javascript" src="Fingerprint.js"></script></head>
<body>
<script type="text/javascript" language="javascript">
if(window.addEventListener)
window.addEventListener("load",get_fingerprint,false);
else
if(window.attachEvent)
window.attachEvent("onload",get_fingerprint);
else
window.onload=get_fingerprint;
</script>
</body>
</html>
<?php
}
else
{
include ("Session.php");
if (defined ("Session_included"))
{
?>
<!DOCTYPE html>
<html>
<head>
<base target="_top">
<meta charset="UTF-8">
<meta http-equiv="content-language" content="de">
<meta http-equiv="content-style-type" content="text/css;charset=utf-8">
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<meta http-equiv="expires" content="0">
<meta http-equiv="pragma" content="no-cache">
<?php
if (!isset ($_POST["Aktion"]))
{
?>
<style>...</style>
</head>
<body>
Bitte melde Dich an, um Zugang zum Verwaltungsbereich zu bekommen:
<form action="<?php echo $_SERVER["PHP_SELF"]; ?>" method="post">
Benutzerkennung: <input name="Benutzer" type="text" value="">
Allgemeines Passwort: <input name="Allgemein" type="text" value="">
Persönliches Passwort: <input name="Persoenlich" type="text" value="">
<input type="submit" value="Anmelden">
<input name="Aktion" type="text" value="Anmelden">
</form>
</body>
</html>
<?php }
else
{
$Aktion = $_POST["Aktion"];
switch ($Aktion)
{
case "Anmelden":
{
...
break;
}
}
}
}
else
echo '"include" ist fehlgeschlagen!';
}
?>
Der $_POST-Wert "Fingerprint" wird erzeugt und auch die Datei "Session.php" korrekt eingebunden, sonst würde ich ja nicht bis zum Anmeldeformular gelangen.
Was habe ich falsch gemacht?
Vielen Dank und Gruß,
Enrico
Tach!
Es wird nach dem Absenden des Anmeldeformulars immer wieder nur das Anmeldeformular angezeigt, der $_POST["Aktion"]-Variable scheint keinerlei Beachtung geschenkt zu werden.
Das Schöne beim Programmieren ist, dass man sich nicht auf den Augenschein verlassen muss. Man kann mit Kontrollausgaben nachschauen, was konkret passiert. Und dann geht man rückwärts in der Entstehungskette von Werten, bis man die Ursache gefunden hat.
Wenn du also aufgrund eines Wertes in $_POST verzweigen möchtest, dann schau dir an, was in $_POST drinsteht. var_dump($_POST); zeigt dir das an. Vorher ein <pre> oder der Blick in die Quelltextansicht des Browsers erhöht die Übersichtlichkeit der Anzeige. phpinfo(INFO_VARIABLES); zeigt dir alles zum Request wichtige an.
Zusätzlich offenbaren vielleicht die Entwicklertools in den Browsers weiteres. Besonders der Netzwerk-Teil, der zeigt dir, wie die Requests aussehen. (Das Häkchen bei Dauerhaft kann nützlich sein, damit nicht Reloads das vorhergehende Ergebnis löschen.)
Nachfolgend der reduzierte Code, den ich hier leider nicht im Multihighlighter-Format formatieren kann:
Man muss nicht jedes Fitzelchen extra auszeichnen, PHP für alles hätte hier völlig gereicht. Ob für das Problem nicht weiter wichtiges HTML richtig ausgezeichnet ist, spielt keine Rolle. Du hättest die unnötigen Teile für eine bessere Übersichtlichkeit auch weglassen können.
dedlfix.
Om nah hoo pez nyeetz, Enrico!
Nachfolgend der reduzierte Code, den ich hier leider nicht im Multihighlighter-Format formatieren kann:
MudGuard
Auge<?php if (!isset ($_POST["Fingerprint"]))
{
?>
[code lang=html]<!DOCTYPE html>
<html>
<head><style>[code lang=css]
html {
display: none;
}
</style></head>
<body>
</body>
</html>[/code]
<?php
}
else
{
?>[/code]
Es wäre aber gegangen …
Matthias
Hi,
ich bin gerade dabei, den Administrationsbereich unserer Bandhomepage zu erstellen.
Zunächst wird geprüft, ob bereits ein Fingerabdruck vom Client erstellt wurde. Wenn nicht, dann wir er erstellt und die Seite aus der Datei "Fingerprint.js" heraus neu aufgerufen.
dann ist die Javascript-Funktion get_fingerprint() offensichtlich von zentraler Bedeutung für das Funktionieren dieses Konzepts. Ausgerechnet die zeigst du uns aber nicht.
Es wird nach dem Absenden des Anmeldeformulars immer wieder nur das Anmeldeformular angezeigt, der $_POST["Aktion"]-Variable scheint keinerlei Beachtung geschenkt zu werden.
Nicht mutmaßen. Prüfen!
Die erste Verzweigung ...
if (!isset ($_POST["Fingerprint"]))
... scheint also zu tun, was du erwartest. Also wird im zweiten Schritt wie gewünscht das Formular angezeigt, da $_POST["Aktion"] nicht da ist.
<?php
if (!isset ($_POST["Aktion"]))
{
> ?>
> ~~~html
<style>...</style>
> </head>
> <body>
> Bitte melde Dich an, um Zugang zum Verwaltungsbereich zu bekommen:
> <form action="<?php echo $_SERVER["PHP_SELF"]; ?>" method="post">
> Benutzerkennung: <input name="Benutzer" type="text" value="">
> Allgemeines Passwort: <input name="Allgemein" type="text" value="">
> Persönliches Passwort: <input name="Persoenlich" type="text" value="">
> <input type="submit" value="Anmelden">
> <input name="Aktion" type="text" value="Anmelden">
> </form>
> </body>
> </html>
Und nach dem Absenden des Formulars geht das Spiel von vorne los, weil bei diesem Request kein $_POST["Fingerprint"] mehr dabei ist. Eigentlich klar, oder?
Übrigens würde ich Eingabefelder für Kennwörter auch als type="password" auszeichnen, dann wird die Eingabe mit Sternchen verschleiert (oder was sonst im jeweiligen GUI üblich ist).
$Aktion = $_POST["Aktion"];
Was hat das Umkopieren hier für einen Zweck? Es ist zwar nicht direkt falsch oder schädlich, aber sinnlos. Weg damit. Warum fragst du $_POST["Aktion"] nicht direkt in der switch-Anweisung ab?
Ciao,
Martin
@@Der Martin:
nuqneH
Übrigens würde ich Eingabefelder für Kennwörter auch als type="password" auszeichnen, dann wird die Eingabe mit Sternchen verschleiert (oder was sonst im jeweiligen GUI üblich ist).
Ich nicht.
Die Verschleierung des Passworts sollte erst auf ausdrücklichen Wunsch des Nutzers geschehen. 'type="text"' als Default, Button oder Checkbox zum Wechsel auf 'type="password"' (und zurück).
Masked Passwords…, Hide/Show Passwords
Qapla'
Die verlinkten Artikel habe ich gesehen. Sie sind auch irgendwie nachvollziehbar. Trotzdem würde es mich ziemlich verstören wenn ein Passwort irgendwo im Klartext angezeigt wird ohne dass ich damit rechne.
Ich gehe eigentlich davon aus dass ich ein Passwort auch in Anwesenheit von anderen eingeben kann und es ohne weiteres Zutun nicht dargestellt wird. Entgegen der Meinung in den Artikeln kommt das durchaus vor. Beispielsweise geschäftlich wenn was über einen Beamer präsentiert wird oder bei Fernwartungen etc. Oder auch einfach zuhause wenn ich jemandem was zeigen will und mich dazu wo anmelde.
Wenn dann würde ich das andersherum machen, der Nutzer soll sagen dass sein Passwort ausdrücklich gezeigt wird. Was natürlich überhaupt gar nicht geht, Passwort nur im Klartext zeigen ohne Möglichkeit zur Umstellung.
'type="text"' als Default, Button oder Checkbox zum Wechsel auf 'type="password"' (und zurück).
Geht nicht der Browser beim Passwörter speichern auf diese Kennzeichnung?
Om nah hoo pez nyeetz, Encoder!
Vor allem bei einer Registrierung würde ich beide Passwortfelder umschaltbar begrüßen oder auch, wenn man als Administrator einen Nutzer anlegt.
Ich plädiere allerdings auch auf type="password" als default.
Matthias
Tach!
Vor allem bei einer Registrierung würde ich beide Passwortfelder umschaltbar begrüßen oder auch, wenn man als Administrator einen Nutzer anlegt.
Wozu braucht es denn noch ein zweites Feld, wenn ich als Nutzer in einem anzeigbaren den Inhalt kontrollieren kann? Der Sinn ist doch, Vertippern beizukommen. Und das kann man ja durch optische Kontrolle mindestens genausogut erreichen.
dedlfix.
Om nah hoo pez nyeetz, dedlfix!
Vor allem bei einer Registrierung würde ich beide Passwortfelder umschaltbar begrüßen oder auch, wenn man als Administrator einen Nutzer anlegt.
Wozu braucht es denn noch ein zweites Feld, wenn ich als Nutzer in einem anzeigbaren den Inhalt kontrollieren kann? Der Sinn ist doch, Vertippern beizukommen. Und das kann man ja durch optische Kontrolle mindestens genausogut erreichen.
Ich bin für höchstens genauso gut ;-)
Man sieht es auch häufig, dass E-Mail-Adressen 2 mal eingegeben werden müssen.
Und über die Tatsache, dass in vielen Fällen das Einfügen aus der Zwischenablage für solche Felder gesperrt ist, kann man ebenfalls geteilter Meinung sein.
Matthias
Moin,
Man sieht es auch häufig, dass E-Mail-Adressen 2 mal eingegeben werden müssen.
Und über die Tatsache, dass in vielen Fällen das Einfügen aus der Zwischenablage für solche Felder gesperrt ist, kann man ebenfalls geteilter Meinung sein.
der Fall, dass C&P nicht möglich war, ist mir noch nicht begegnet*.
Und ich überlege gerade, wie das überhaupt realisiert werden könnte.
Zumindest das Einfügen aus der Zwischenablage _in_ ein beliebiges Eingabefeld war in den Fällen, die ich bisher gesehen habe, immer möglich.
Ciao,
Martin
* Ich meine ausdrücklich nicht das Kopieren _aus_ einem Passwort-Feld. Das Thema hatten wir ja erst neulich.
Mahlzeit,
Man sieht es auch häufig, dass E-Mail-Adressen 2 mal eingegeben werden müssen.
Tierisch nervig.
Und über die Tatsache, dass in vielen Fällen das Einfügen aus der Zwischenablage für solche Felder gesperrt ist, kann man ebenfalls geteilter Meinung sein.
Doppel- oder Dreifachklick zum markieren und mittlere Maustaste zum einfügen. Eines der vielen Features, die mir unter Windows extrem fehlen.
Zumindest das hat mir noch kein Browser verweigert, kann aber sein, das es Zufall ist.
Mahlzeit,
Die Verschleierung des Passworts sollte erst auf ausdrücklichen Wunsch des Nutzers geschehen. 'type="text"' als Default, Button oder Checkbox zum Wechsel auf 'type="password"' (und zurück).
Juchu, Und jeder, der unbemerkt hinter dir steht, kann dein Passwort mitlesen.
Das ist in etwa so als wenn du die Tür erst zusperrst, wenn du einen Einbrecher vor dem Haus siehst. Wenn du ihn allerdings übersiehst, hast du ein Problem.
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
Die Verschleierung des Passworts sollte erst auf ausdrücklichen Wunsch des Nutzers geschehen. 'type="text"' als Default, Button oder Checkbox zum Wechsel auf 'type="password"' (und zurück).
Juchu, Und jeder, der unbemerkt hinter dir steht, kann dein Passwort mitlesen.
Das ist wahr, aber den Fall halte schon für recht konstruiert und glaube nicht, dass es in der Wirklichkeit häufig dazu kommt. Diesen Tradeoff würde ich deshalb zu Gunsten der Usability eingehen.
Noch besser wäre eine Lösung ganz ohne Passwörter auf Basis von digitalen Signaturen, das ist aber leider noch nicht Mainstream-fähig und wird es vielleicht auch nie werden.
Mahlzeit,
Das ist wahr, aber den Fall halte schon für recht konstruiert und glaube nicht, dass es in der Wirklichkeit häufig dazu kommt. Diesen Tradeoff würde ich deshalb zu Gunsten der Usability eingehen.
Hast du schon mal in nem Grossraum-Büro gearbeitet? Deiner Aussage nach behaupte ich: Nein. Kein Vorwurf, aber solche Situationen sind alles andere als konstruiert, es gibt massenhaft Fälle, an denen Passwörter an der Tastatur beim Tippen "abgelesen" wurden, diesen "Spannern" machst du das Leben richtig schön, wenn du das Passwort im Klartext anzeigst.
Noch besser wäre eine Lösung ganz ohne Passwörter auf Basis von digitalen Signaturen, das ist aber leider noch nicht Mainstream-fähig und wird es vielleicht auch nie werden.
Und wie willst du das umsetzen?
Hab ich eine Technik vergessen, die überhaupt Chancen hätte, sinnvoll eingesetzt zu werden? Klar, bei mobilen Geräten wird NFC bald überall drinnen sein, aber dass es sich bei normalen PCs durchsetzt, bezweifel ich stark.
Wenn ich was vergessen hab, her damit, bin da kein Spezialist, aber ich finde das Thema sehr interessant.
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
Das ist wahr, aber den Fall halte schon für recht konstruiert und glaube nicht, dass es in der Wirklichkeit häufig dazu kommt. Diesen Tradeoff würde ich deshalb zu Gunsten der Usability eingehen.
Hast du schon mal in nem Grossraum-Büro gearbeitet?
Ich arbeite auch in einem Großraum-Büro und habe trotzdem noch nie von einem Angriff dieser Art gehört oder gelesen, das sind unsere Erfahrungen einfach unterschiedlich. Das hypothetische Szenario besteht halt, aber Fakten und Zahlen lassen sich dazu auch kaum finden. Der wahrscheinlichere Fall, dass jemand hinter einem steht und man davon weiß, wird durch das optionale "Passwort verchleiern"-Häkchen ja abgedeckt.
Noch besser wäre eine Lösung ganz ohne Passwörter auf Basis von digitalen Signaturen, das ist aber leider noch nicht Mainstream-fähig und wird es vielleicht auch nie werden.
Und wie willst du das umsetzen?
Der Schlüssel muss entweder im Browser oder im Betriebssystem installiert werden.
- Schlüssel auf dem Rechner ist zu 100% unsicher, sobald mehr als eine Person an den Rechner kommt.
Nö digitale Signaturen sind ja auch verschlüsselt und passwort-geschützt.
Hab ich eine Technik vergessen, die überhaupt Chancen hätte, sinnvoll eingesetzt zu werden?
Okay, ich war da zu undeutlich in meiner ersten Antwort. Signaturen sind selbst natürlich auch durch Passworte geschützt, die Passwort-Abfrage findet aber nicht auf Webseiten-Ebene statt, sondern kann zum Beispiel beim Login im OS-Benutzer-Account oder beim Login im Browserprofil geschehen.
Das erfordert natürlich Computer-Kenntnisse die über Office und Powerpoint hinaus gehen und außerdem eine gewisse Disziplin im Umgang mitprivaten Schlüsseln. Deshalb halte ich das nicht für den Mainstream geeignet, für erfahrene Nutzer kann das aber durchaus Komfort bieten.
Hi,
Nö digitale Signaturen sind ja auch verschlüsselt und passwort-geschützt.
Dann muß also wieder ein Paßwort eingegeben werden - das dabei wieder ausgespäht werden kann.
Und wenn der User selbst nach unbeobachteter Paßworteingabe vergißt, sich für die Mittagspause auszuloggen, kann jeder ...
Oder wenn er nur mal für eine kurze Frage ins Nachbarbüro geht - und dort dann länger bleibt als beabsichtigt ...
Oder ...
Hilft also nur, wenn bei Untätigkeit sehr schnell der Bildschirmschoner zuschlägt - und der nur mit Paßwort wieder freigeschaltet werden kann.
Aber die Paßworteingabe sollte ja möglichst - wegen des Ausspähens durch den Hintermann - vermieden werden ...
cu,
Andreas
Tach!
Und wenn der User selbst nach unbeobachteter Paßworteingabe vergißt, sich für die Mittagspause auszuloggen, kann jeder ...
Oder wenn er nur mal für eine kurze Frage ins Nachbarbüro geht - und dort dann länger bleibt als beabsichtigt ...
Oder ...
Windows + L und ggf. noch einmal Enter ist die schnellste Methode unter Windows. Abgesehen davon ist das Offenlassen fahrlässig, das Ausnutzen jedoch vorsätzlich.
Hilft also nur, wenn bei Untätigkeit sehr schnell der Bildschirmschoner zuschlägt - und der nur mit Paßwort wieder freigeschaltet werden kann.
Das ist besonders nervig, wenn man nur mal im einen längeren Text liest und nebenbei was auf Papier schreibt, und dann nicht mal das schnelle Mauswackeln den Bildschirmschoner zum Einlenken bringt. Bei Windows 7 konnte man das noch tun, Windows 8 ist diesbezüglich leider wieder gnadenlos geworden.
Aber die Paßworteingabe sollte ja möglichst - wegen des Ausspähens durch den Hintermann - vermieden werden ...
Die sind auch im Großraumbüro weit genug weg. Lediglich wenn sich der Hintermann umdreht, könnte man nicht schnell genug reagieren, um zum Verdecken-Button zu gelangen. Windows 8 (oder wars erst 8.1?) hat das kleine Auge in Passwort-Feldern, mit dem man (nur) während der Eingabe selbige bei Bedarf sichtbar machen kann.
dedlfix.
Om nah hoo pez nyeetz, dedlfix!
Windows 8 (oder wars erst 8.1?) hat das kleine Auge in Passwort-Feldern, mit dem man (nur) während der Eingabe selbige bei Bedarf sichtbar machen kann.
oder war es der IE?
Matthias
Tach!
Windows 8 (oder wars erst 8.1?) hat das kleine Auge in Passwort-Feldern, mit dem man (nur) während der Eingabe selbige bei Bedarf sichtbar machen kann.
oder war es der IE?
Der auch, aber auch beim Anmelden gibts das Auge.
dedlfix.
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
Nö digitale Signaturen sind ja auch verschlüsselt und passwort-geschützt.
Dann muß also wieder ein Paßwort eingegeben werden - das dabei wieder ausgespäht werden kann.
Das ist richtig, mit einer reinen Software-Lösung wird man das auch nicht lösen können, dafür bräuchte man entsprechende Hardware.
Und wenn der User selbst nach unbeobachteter Paßworteingabe vergißt, sich für die Mittagspause auszuloggen, kann jeder ...
Oder wenn er nur mal für eine kurze Frage ins Nachbarbüro geht - und dort dann länger bleibt als beabsichtigt ...
Oder ...
Das Problem stellt sich bei Pro-Webseiten-Passwort-Abfrage auch.
Aber die Paßworteingabe sollte ja möglichst - wegen des Ausspähens durch den Hintermann - vermieden werden ...
Mit Client-Zertifikaten kann man die Häufigkeit der Passwort-Abfrage schon deutlich verringern, um sie ganz abzuschütteln könnte man zum Beispiel auf Hardware-Tokenizer setzen. Das ist aus Usability-Sicht dann aber wieder ein Schritt zurück.
Um die Idee von Client-Zertifkikaten mal greifbar zu machen: Bei SSH Remote-Shells werden diese zum Beispiel eingesetzt und auch bei GitHub weiß man sie zu schätzen.
Hallo
Hast du schon mal in nem Grossraum-Büro gearbeitet?
Ich arbeite auch in einem Großraum-Büro und habe trotzdem noch nie von einem Angriff dieser Art gehört oder gelesen, das sind unsere Erfahrungen einfach unterschiedlich.
Solche Angriffe gab's aber schon. Natürlich sind die nicht alltäglich, wäre ja schlimm, wenn man auf Arbeit nur von misstrauenswürdigen Menschen umgeben wäre.
Das hypothetische Szenario besteht halt, aber Fakten und Zahlen lassen sich dazu auch kaum finden. Der wahrscheinlichere Fall, dass jemand hinter einem steht und man davon weiß, wird durch das optionale "Passwort verchleiern"-Häkchen ja abgedeckt.
Mit dem Passwort-verschleiern-Häkchen und damit mit Gunnars Ansinnen habe ich ein Usability-Problem. Ich muss davon ausgehen, dass ich – und ich wette, nicht nur ich – in den relevanten Situationen dann und wann vergesse, die Funktion zu benutzen. Damit ist sie als zusätzliche Sicherheitsfunktion unbrauchbar.
Mal abgesehen davon, dass alle mir bekannten Betriebssysteme und Browser die Passworte mit Punkten oder Sternen darstellen und eben nicht im Klartext anzeigen, ich als Benutzer also genau dieses Verhalten gewohnt bin, möchte ich den Komfortgewinn, die Eingabe prüfen zu können, nicht abstreiten. Wenn, dann wäre mir aber die standardmäßig verschleierte Anzeige aber lieber. Mich vor der Prüfung im Klartext kurz zu gucken, ob keiner guckt, halte ich für sinnvoller.
Tschö, Auge
@@M.:
nuqneH
Die Verschleierung des Passworts sollte erst auf ausdrücklichen Wunsch des Nutzers geschehen. 'type="text"' als Default, Button oder Checkbox zum Wechsel auf 'type="password"' (und zurück).
Juchu, Und jeder, der unbemerkt hinter dir steht, kann dein Passwort mitlesen.
Den Fall, dass jemand, der mir Böses will, sich zufällig auch noch just in dem Moment unbemerkt von hinten anschleicht, in dem ich ein Passwort eingebe, scheint mir jetzt sehr weit hergeholt.
Ich sehe 3 Fälle:
1. Mobiles Gerät. Bei Eingabe über Tastatur werden die Zeichen kurz angezeigt – auf dem iPhone sogar in groß. Jeder, der über die Schulter schaut, kann sowieso das Passwort mitlesen; die Verschleierung macht überhaupt keinen Sinn. (Aufgrund der Größe des Gerätes und der Art, wie man es hält, ist es aber unwahrscheinlich, dass jemand unbemerkt über die Schulter schauen kann.)
2. Desktop, private Nutzung. Passwortanzeige im Klartext unproblematisch.
3. Desktop, im Büro, Internetcafé etc. Nutzer ist sich der Umgebung bewusst. Spätestens beim zweiten eingegebenen Zeichen sollte ihm klar sein, dass es besser wäre, das Passwort nicht im Klartext anzeigen zu lassen; er schaltet um und gibt die restlichen Zeichen blind ein. (Dass Passwörter deutlich länger als 2 Zeichen sein sollten, darüber müssen wir uns wohl nicht unterhalten.)
In Fall 1 und 2 ist die Voreinstellung Passwortanzeige als Klartext vorteilhaft, in Fall 3 auch nicht wirklich problematisch.
Was aber sicher sinnvoll ist, ist die vom Nutzer gewünschte Art der Passwortanzeige im LocalStorage (oder Cookie) festzuhalten und beim nächsten Besuch der Seite wieder so anzubieten.
Qapla'
Om nah hoo pez nyeetz, Gunnar Bittersmann!
- Desktop, im Büro, Internetcafé etc. Nutzer ist sich der Umgebung bewusst. Spätestens beim zweiten eingegebenen Zeichen sollte ihm klar sein, dass es besser wäre, das Passwort nicht im Klartext anzeigen zu lassen; er schaltet um und gibt die restlichen Zeichen blind ein.
Wenn man das Passwort auswendig kennt und nicht perfekt und blind 130 Zeichen pro Minute auf der Tastatur schreibt, tippt man es ein, ohne dass man auf den Bildschirm schaut.
Da dies nach meinem Empfinden den größten Anteil der Nutzer darstellt, sollte das Passwort in der Defaulteinstellung versternt werden.
Matthias
Hallo,
Wenn man das Passwort auswendig kennt und nicht perfekt und blind 130 Zeichen pro Minute auf der Tastatur schreibt, tippt man es ein, ohne dass man auf den Bildschirm schaut.
würde ich auch behaupten. Wirklich gute, ausgebildete "Tastenschreiber" tippen zwar blind, d.h. ohne auf die Tastatur zu schauen - stattdessen auf den Bildschirm oder auf die Vorlage. Bei den weniger routinierten ist eher das Gegenteil der Fall.
Ich würde mich zwar als geübten Schreiber einordnen, aber auch bei mir ist der Blick beim Tippen vor allem auf der Tastatur.
Da dies nach meinem Empfinden den größten Anteil der Nutzer darstellt, sollte das Passwort in der Defaulteinstellung versternt werden.
+1
Ciao,
Martin
Hallo,
Bei Eingabe über Tastatur werden die Zeichen kurz angezeigt – auf dem iPhone sogar in groß. Jeder, der über die Schulter schaut, kann sowieso das Passwort mitlesen;
Dazu müsste der "Angreifer" die ganze Zeit während der Eingabe auf den letzten Buchstaben achten.
Das ist zwar möglich, aber schwieriger als das Passwort auf einen Blick zu sehen.
Diese Umsetzung ist ein guter Kompromiss zwischen Sicherheit (Verschleierung) und Komfort (Sichtbarkeit).
die Verschleierung macht überhaupt keinen Sinn.
Doch, sie macht Sinn.
(Aufgrund der Größe des Gerätes und der Art, wie man es hält, ist es aber unwahrscheinlich, dass jemand unbemerkt über die Schulter schauen kann.)
Nein. Mobil-Geräte werden in der Öffentlichkeit benutzt, wo jeder unbemerkt über die Schulter schauen kann. Zum Beispiel im öffentlichen Nahverkehr, wo alle auf ihren Handys herumspielen.
- Desktop, private Nutzung. Passwortanzeige im Klartext unproblematisch.
Nein. Auch Freunde und Familienmitglieder sollen meine Passwörter nicht im Vorbeigehen sehen können.
Wenn lange Passphrases anstatt zufällige Zeichenkombinationen benutzt werden, ist ein schneller Blick möglich, um sie sich komplett oder größtenteils zu merken.
- Desktop, im Büro, Internetcafé etc. Nutzer ist sich der Umgebung bewusst.
Daher ist es wichtig, SICHERE DEFAULTS zu bieten!
Spätestens beim zweiten eingegebenen Zeichen sollte ihm klar sein, dass es besser wäre, das Passwort nicht im Klartext anzeigen zu lassen;
Das ist doch nicht benutzerfreundlich! Sicherheit sollte PER DEFAULT aktiviert sein, nicht ein zusätzliches Feature, dass der Nutzer erst anschalten muss, weil er merkt, dass er gerade angreifbar ist.
Oliver
@@Oliver D.:
nuqneH
Spätestens beim zweiten eingegebenen Zeichen sollte ihm klar sein, dass es besser wäre, das Passwort nicht im Klartext anzeigen zu lassen;
Das ist doch nicht benutzerfreundlich!
Passwörter sind generell nicht nutzerfreundlich.
Und natürlich ist es nutzerfreundlich, für eine Einstellung einen sinnvollen Default zu wählen. Für mich ist es Passwort im Klartext anzeigen. YMMV.
Wie dem auch sei, wenn sich die Einstellung gemerkt wird, ist der Default nur beim ersten Seitenbesuch relevant.
Qapla'
Mahlzeit,
Den Fall, dass jemand, der mir Böses will, sich zufällig auch noch just in dem Moment unbemerkt von hinten anschleicht, in dem ich ein Passwort eingebe, scheint mir jetzt sehr weit hergeholt.
Dafür haben schon reichlich böse Buben extra Kameras installiert. Ein "es kann jemand hinter dir stehen", ist nicht immer wortwörtlich zu nehmen.
- Desktop, im Büro, Internetcafé etc. Nutzer ist sich der Umgebung bewusst. Spätestens beim zweiten eingegebenen Zeichen sollte ihm klar sein, dass es besser wäre, das Passwort nicht im Klartext anzeigen zu lassen; er schaltet um und gibt die restlichen Zeichen blind ein.
Du traust also jedem Computer-Benutzer zu, soviel mitzudenken? Ich nicht, und vermutlich tausende Support-Mitarbeiter auch nicht.Es gilt immer noch "Rechne mit dem Schlimmsten und hoffe das Beste".
Es ist und bleibt Geschmacksache, ich bin der Meinung (und bleibe dabei), per Default Sternchen, als Option Klartext.
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
Die Verschleierung des Passworts sollte erst auf ausdrücklichen Wunsch des Nutzers geschehen.
Da stimme ich zu, aber noch mehr würde ich mir wünschen, dass die Browser ihre Passwort-Eingabefelder schon so implementieren. Denn die sind auch für Verwaltung von Passworten zuständig und die automatische Speicherung ist auch ein enormer Usability-Gewinn, den man mit einem eigenen Hack aufgibt oder umständlich nachbauen muss.
$Aktion = $_POST["Aktion"];
Was hat das Umkopieren hier für einen Zweck?
Vieles bei PHP hat keinen Zweck, nur einen Grund: Das machen alle so.™
Mahlzeit,
Vieles bei PHP hat keinen Zweck, nur einen Grund: Das machen alle so.™
Praxisrelevante Beispiel, ausser das Umkopieren?
Hi,
Vieles bei PHP hat keinen Zweck, nur einen Grund: Das machen alle so.™
Praxisrelevante Beispiel, ausser das Umkopieren?
echo "$variable";
cu,
Andreas
Tach!
Vieles bei PHP hat keinen Zweck, nur einen Grund: Das machen alle so.™
Praxisrelevante Beispiel, ausser das Umkopieren?
echo "$variable";
Das war jetzt Ironie?
In der freien Wildbahn kommt so etwas theoretisch nicht vor, weil dabei der Kontextwechsel nicht beachtet werden kann. Bessere Konstrukte:
echo htmlspecialchars($_POST[...]);
oder eingebettet in einen anderen Wert:
printf('<foo>%s</foo>', htmlspecialchars());
dedlfix.
Hi,
Vieles bei PHP hat keinen Zweck, nur einen Grund: Das machen alle so.™
Praxisrelevante Beispiel, ausser das Umkopieren?
echo "$variable";Das war jetzt Ironie?
In der freien Wildbahn kommt so etwas theoretisch nicht vor, weil dabei der Kontextwechsel nicht beachtet werden kann.
Das ist eben der Unterschied zwischen Theorie und PHP äh Praxis.
"$variable" sieht man hier sehr oft in Fragen zu PHP.
Und es ging ja um Dinge, die keinen Zweck haben ...
cu,
Andreas
Tach!
Vieles bei PHP hat keinen Zweck, nur einen Grund: Das machen alle so.™
Praxisrelevante Beispiel, ausser das Umkopieren?
echo "$variable";
Das war jetzt Ironie?
In der freien Wildbahn kommt so etwas theoretisch nicht vor, weil dabei der Kontextwechsel nicht beachtet werden kann.
Achja, praxisrelevante Undinge war ja das Thema, dann passt das unironisiert dazu.
dedlfix.
Mahlzeit,
echo "$variable";
Ich kenn sowas schon, von Leuten, die gerne Programmierer sein möchten. Im professionellen Umfeld ist mir das bisher nicht untergekommen.
Ich halte Foren/Tutorials, sie sowas zeigen, nur für bedingt Praxisrelevant ;)
Aber es stimmt natürlich, PHP ermöglich miesen Code und der wird dann auch fabriziert. Ich bin vermutlich nur verwöhnt :D
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
$Aktion = $_POST["Aktion"];
Was hat das Umkopieren hier für einen Zweck? Es ist zwar nicht direkt falsch oder schädlich, aber sinnlos. Weg damit. Warum fragst du $_POST["Aktion"] nicht direkt in der switch-Anweisung ab?
Ich mache das auch ziemlich häufig. Es ist einfach eine kleine Abstraktion, wenn ich den Wert im weiteren Programm-Ablauf wieder und wieder verwende, dann interessiert mich an diesen Stellen oft nicht mehr, wie ich an diesen Wert gekommen bin. Ob er aus $_POST oder $_GET oder aus irgendeiner anderen Quelle stammt ist dann häufig einfach nicht mehr relevant und eine eigene Variable kann dieses Implementations-Detail verstecken. Das macht den Quellcode leserlicher. Und wenn sich die Quelle zu einem späteren Zeitpunkt ändern sollte, muss man nur an einer einzigen Stelle diese Änderung vornehmen.
Mahlzeit,
Das macht den Quellcode leserlicher. Und wenn sich die Quelle zu einem späteren Zeitpunkt ändern sollte, muss man nur an einer einzigen Stelle diese Änderung vornehmen.
An sich sind deine Ausführungen schon richtig, aber wenn mehrere Leute am Code arbeiten, kann es zu Problemen kommen, wenn ein Programmierer $POST[] verwendet und ein anderer den kopierten Wert. Da kommt es schnell zu Konflikten, wenn der Wert sich im Programmablauf ändert.
Das kann man natürlich durch eine exakte Dokumentation umgehen, dann musst du aber zweimal den gleichen Wert dokumentieren, was mehr Aufwand bedeutet und beim Bearbeiten der Doku das Risiko birgt, dass einer der Werte evtl. in der Doku nicht berücksichtigt wird.
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
An sich sind deine Ausführungen schon richtig, aber wenn mehrere Leute am Code arbeiten, kann es zu Problemen kommen, wenn ein Programmierer $POST[] verwendet und ein anderer den kopierten Wert. Da kommt es schnell zu Konflikten, wenn der Wert sich im Programmablauf ändert.
Ja, das muss man ja nicht für jede Variable einzeln dokumentieren, es reicht aus das in einem Styleguide für den allgemeinen Fall festzuhalten.
Ansonsten kann man statt einer Kopie auch eine Referenz benutzen um die Inkonsitenz zu vermeiden.
Mahlzeit,
Ja, das muss man ja nicht für jede Variable einzeln dokumentieren, es reicht aus das in einem Styleguide für den allgemeinen Fall festzuhalten.
Dann hast du noch nie für eine Firma wie T-Sytems gearbeitet (und auch andere, die ein eigenes Qualitätsmanagement für Dokumentationen haben. Auf 25 Projektteilnehmer kommen grad mal 5 Programmierer) ;)
Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?
Mahlzeit,
Ja, das muss man ja nicht für jede Variable einzeln dokumentieren, es reicht aus das in einem Styleguide für den allgemeinen Fall festzuhalten.
Dann hast du noch nie für eine Firma wie T-Sytems gearbeitet (und auch andere, die ein eigenes Qualitätsmanagement für Dokumentationen haben. Auf 25 Projektteilnehmer kommen grad mal 5 Programmierer) ;)
Für T-Systems habe ich noch nicht gearbeitet und würde ich auch nicht wollen, wenn deren Workflow so unsinnige Dokumentation vorsieht. Jede Variable zu dokumentieren ist einfach Unsinn, dann kann ich auch direkt den Quelltext lesen. Eine gute Dokumentation behandelt verwendete Muster und logisch geschichte Schnittstellen-Dokumentation. Eine zeilenweise oder ausdrucksweise Dokumentation bietet gegenüber dem reinen Quelltext kaum einen Mehrwert, es macht nur unnötige Arbeit die Dokumentation mit dem Quelltext synchron zu halten. Feingranulare Dokumentation kann fallls nötig in Form von Quelltext-Kommentaren stattfinden, aber das ist unter keinen Umständen der Einstiegspunkt für Entwickler, die sich einen Überblick über die Architektur der Software verschaffen möchten. Um einen Entwickler das zu ermöglichen muss schon sehr viel gedankliche Abstraktion in die Niderschrift eingeflossen sein, da haben interne Variablen-Bezeichner nichts mehr verloren.
Um die Code-Qualität zu garantieren sind zudem Modul-Tests ein häufig verwendetes Werkzeug. Es ist doch viel beruhigender zu wissen, dass ein gewisses Modul das tut, was es soll, anstatt zu wissen, wie es das macht. Styleguides habe ich ja schon genannt, die lassen sich übrigens teilweise auch automatisiert validieren. Es gibt viele, viele weiteren Werkzeuge, um die Code-Qualität zu gewährleisten, speziell für JavaScript gibt es idiomatic.js auf GitHub, das öffentliche Repository dokumentiert solche Code-Quality-Tools. Mit einer breiten Palette aus diesem Werkzeugkasten ist man deutlich besser und effizienter aufgestellt als mit stupider und gedankenloser Quelltext-Dokumentation.
Mahlzeit,
Jede Variable zu dokumentieren ist einfach Unsinn, dann kann ich auch direkt den Quelltext lesen.
Dazu müsste der Dokumentator (schreibt man den so?) aber zumindest ansatzweise was vom Programmieren verstehen.
Eine gute Dokumentation behandelt verwendete Muster und logisch geschichte Schnittstellen-Dokumentation. Eine zeilenweise oder ausdrucksweise Dokumentation bietet gegenüber dem reinen Quelltext kaum einen Mehrwert, es macht nur unnötige Arbeit die Dokumentation mit dem Quelltext synchron zu halten.
Der Mehrwert ist, dass die Laien in der Chefetage glauben zu verstehen, was die Software macht.
Um die Code-Qualität zu garantieren sind zudem Modul-Tests ein häufig verwendetes Werkzeug.
Die macht dann ein weiteres Team, das einige hundert km weg arbeitet, in einer anderen Server-Infrastruktur sitzt, andere Entwicklungsumgebungen hat und mit der Doku nix anfangen kann, weil sie ein Laie geschrieben hat.