HTML mit Passwort aber ohne User Eingabe!

[Tazzi]

Hi. Ich hab folgendes Problem: Ich möchte eine einzige .HTML mit einem Passwort schützen. Also zb kennt jemand den Link: geo.tazzi.org Den gibt er ein. Dann landet er auf (muss so sein, fragt nicht warum ;) ) tazzi.org/GeoAnimalsWalk/index.html Aber: es soll dann ein Feld auftauchen, in dem er das Passwort eingeben soll. Keinen User!

Ist das PW korrekt, soll er auf tazzi.org/GeoAnimalsWalk/gccoords.html geleitet werden. Darf aber die gccoords.html keines Falls direkt aufrufen können (um zb das PW nicht kennen zu müssen) Alles, was ich bisher gefunden hab, war immer mit User. Und ein Script ohne, das ich fand, funktioniert nicht richtig.

Kann mir da wer helfen?

LG Tazzi

[TS]

Hello,

Du kannst mit einer Session arbeiten und wenn das Passwort noch nicht eingegeben wurde, die Ausgabe der "geschützten" Seite verweigern.

Die Ressourcen müssen daher alle "aktive" Ressourcen sein, die sich selber schützen können...
In jeder Ressource muss also (am Anfang) der Testcode auf das Passwort enthalten sein.

Anderenfalls müssen die Ressourcen außerhalb der Document Root gespeichert werden, damit man nicht ohne Passwort direkt per http/s darauf zugreifen kann.

Du solltest dann aber auf jeden Fall ein Log schreiben, in dem mit IP und Datum-Teit vermerkt ist, ob der Anmeldeversuch geklappt hat, oder nicht. Das kannst Du dann z. B. mittels fail2ban oder Nachfolger auf Bruteforce überwachen.

Sonst ist diese Konstruktion quasi offen, wie ein Scheunentor.

Liebe Grüße
Tom S.

[einsiedler]

Nee, das wird NIX mehr! mmmgrumpf

[Matthias Apsel]

Hallo Tazzi,

es sollen alle Benutzer den Benutzernamen "" haben – Warum können sie nicht alle den Benutzernamen "User" haben dürfen? Dann könntest du das Verzeichnis schützen https://wiki.selfhtml.org/wiki/Webserver/htaccess/Passwortschutz

Bis demnächst
Matthias

[Tazzi]

Hallo, von mir aus können sie jeden Benutzernamen haben. Aber sie sollten weder einen kennen, noch ihn eingeben müssen. Es ist ne Art Schnipseljagd, bei der sie das Passwort gefunden haben, dann noch n User ist zu viel. Zumal ich die Leute nicht kenne, bis sie sich mit dem Passwort einloggen

[JürgenB]

Hallo,

wäre es auch eine Option, das der Dateiname geheim ist? Also wenn das Passwort „aLLesgeFUNden“ lautet, ist die gewünschte Datei https://tazzi.org/GeoAnimalsWalk/aLLesgeFUNden.html oder auch nur https://tazzi.org/GeoAnimalsWalk/aLLesgeFUNden. Das kann der User direkt eingeben, oder du baust eine Eingangseite, die über ein <input type="passwort"> das Passwort abfragt, per Javascript daraus die URL erstellt und über location.href an dieses Seite weiterleitet. Bei falschem Passwort kommt dan vom Server die Not-Found-Meldung.

Gruß
Jürgen

[TS]

Hello,

wäre es auch eine Option, das der Dateiname geheim ist?

Zugangsdaten sollte man nie per GET-Request übertragen, sondern immer nur per HTTPs und POST-Request.

Es gilt das ungeschriebene Gesetz, dass Post-Daten nicht in Suchmaschinen gelistet werden, was bei Übertragung per HTTPs auch ohne Zutun des Zielserver nicht möglich sein sollte!

Der Erstrequest per GET könnte aber auf eine unverschlüsselte Seite gehen, die dann auf eine verschlüsselte umleitet oder zumindest den Post-Request (im Action-Attribut des Login-Forms) verschlüsselt aushandelt.

Liebe Grüße
Tom S.

[JürgenB]

Hallo,

wäre es auch eine Option, das der Dateiname geheim ist?

Zugangsdaten sollte man nie per GET-Request übertragen, sondern immer nur per HTTPs und POST-Request.

es handelt sich um ein Spiel, nicht um Homebanking.

Gruß
Jürgen

[TS]

Hello,

wäre es auch eine Option, das der Dateiname geheim ist?

Zugangsdaten sollte man nie per GET-Request übertragen, sondern immer nur per HTTPs und POST-Request.

es handelt sich um ein Spiel, nicht um Homebanking.

Was willst Du damit jetzt genau sagen?

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Zugangsdaten sollte man nie per GET-Request übertragen, sondern immer nur per HTTPs und POST-Request.

es handelt sich um ein Spiel, nicht um Homebanking.

Was willst Du damit jetzt genau sagen?

Dass die Sicherheitsstandards, die du hier anlegen möchtest, deutlich am Ziel des TO vorbeischießen. Der TO sucht nicht nach Sicherheit, sondern nach Pseudo-Sicherheit. Ein Spiel eben.

Grüße,

RIDER

[TS]

Hello,

Zugangsdaten sollte man nie per GET-Request übertragen, sondern immer nur per HTTPs und POST-Request.

es handelt sich um ein Spiel, nicht um Homebanking.

Was willst Du damit jetzt genau sagen?

Dass die Sicherheitsstandards, die du hier anlegen möchtest, deutlich am Ziel des TO vorbeischießen. Der TO sucht nicht nach Sicherheit, sondern nach Pseudo-Sicherheit. Ein Spiel eben.

Aber unser Motto "Die Energie des Verstehens" gilt noch?
Dann lass uns doch nicht das Pfuschen anfangen!

Ich habe schon nur das Nötigste gezeigt (siehe berechtigte Einwände von 1unitedpower), um das Verfahren erklären zu können, und ich denke, dass Tazzi soweit auch folgen konnte.

Und wer weitere Ideen hat, die vernünftig sind (also kein Pfusch!), der sollte sie auch mit Beispiel zeigen und nicht nur Kritik üben...

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Aber unser Motto "Die Energie des Verstehens" gilt noch?
Dann lass uns doch nicht das Pfuschen anfangen!

Ein Kind möchte, dass du ihm eine Sandburg baust. Du sagst, klar, gar kein Problem, engagierst ein Team von Architekten, kaufst ein Grundstück und lässt die nächsten 10 Jahre lang darauf das stabilste Hochhaus der Welt errichten.

Kann man schon machen.

Aber wenn ich zu einem Kind komme, das eine Sandburg haben möchte, dann baue ich ihm für gewöhnlich eine Sandburg.

Wenn die Sandburg dir dann von der Spitze deines Hochhauses gesehen vorkommt wie Pfusch, dann könnte es durchaus gut sein, dass deine Architekten Elfenbein als Rohstoff zum Hochhausbau bevorzugt haben.

Übrigens könnts durchaus sein, dass infolge davon andere Kinder, die eigentlich nur eine Sandburg haben wollten, in Zukunft gar keine mehr bauen möchten, weil sie irrtümlicherweise davon ausgehen, dass man zum Bau einer Sandburg zunächst den höchsten Elfenbeinturm der Welt errichten muss.

Grüße,

RIDER

[1unitedpower]

Aber wenn ich zu einem Kind komme, das eine Sandburg haben möchte, dann baue ich ihm für gewöhnlich eine Sandburg.

Nur weil Metaphern so schön sind: Tom hat die Sandburg gebaut, Jürgen hat einen Sandkuchen gebacken. Auf einem Elfenbeinturm sitzt keiner der beiden, da hast du die Metapher meiner Meinung nach zu weit getrieben.

[Camping_RIDER]

Aloha ;)

Aber wenn ich zu einem Kind komme, das eine Sandburg haben möchte, dann baue ich ihm für gewöhnlich eine Sandburg.

Nur weil Metaphern so schön sind: Tom hat die Sandburg gebaut, Jürgen hat einen Sandkuchen gebacken. Auf einem Elfenbeinturm sitzt keiner der beiden, da hast du die Metapher meiner Meinung nach zu weit getrieben.

Ich glaube unser Verständnis davon, was eine Sandburg ist und was nicht, geht einigermaßen auseinander.

Und ich gebs zu, der Elfenbeinturm war eine Übertreibung, aber es hat so schön geklungen.

Trotzdem glaube ich, dass der Thread an den Anforderungen meilenweit vorbeischießt. Was nicht schlimm ist. Vielleicht lernt jemand was dabei. Aber im Sinne einer Kosten-Nutzen-Analyse sind die propagierten Lösungen eventuell bedenklich (weil nicht Problem-angepasst).

Oder, um in deiner Metapher-Variante zu bleiben: Vielleicht wollte das Kind ja nur einen Sandkuchen. Oder einen Sandmuffin.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Vielleicht wollte das Kind ja nur einen Sandkuchen. Oder einen Sandmuffin.

Protip: Hör nicht auf das, was Nutzer wollen. Gib ihnen das, was sie brauchen.

Mit Henry Fords (Autobauer) Worten: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.“

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Vielleicht wollte das Kind ja nur einen Sandkuchen. Oder einen Sandmuffin.

Protip: Hör nicht auf das, was Nutzer wollen. Gib ihnen das, was sie brauchen.

Mit Henry Fords (Autobauer) Worten: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.“

Guter Tipp, aber auch der verfehlt hier mMn das Thema. Denn der Tipp beinhaltet „was sie brauchen“, beinhaltet also eine Komponente, die sehr anforderungszentriert ist, und dann landet man hier auch wieder beim Sandmuffin.

So kommt mir der Satz mehr vor wie eine Binsenweisheit, die zwar wahr ist, der Diskussion hier aber nicht so wirklich gerecht wird.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Aber unser Motto "Die Energie des Verstehens" gilt noch?

Du zitierst hier "Die Energie des Verstehens". Das ist sehr löblich.

Aber sag mir: Worin liegt mehr Verständnis:

Nutzern beizubringen, wann warum welche Maßnahme Sicherheit bringt, um sie zu befähigen, Sicherheitskonzepte einzuordnen und auch in Zukunft selbst mit Verstand zu bewerten?

Oder im Moment allgemeingültige Sicherheitsstandards einfach vorzulegen, ohne den Nutzer daran heranzuführen, warum man wo welches Sicherheitsmerkmal fordert, und ihn das ausführen lassen?

---

Meiner Meinung nach hast du (und auch @1unitedpower) in diesem Thread hier eher zweiteres als ersteres getan. Denn ansonsten hätte man wohl auch auf den Prüfstand stellen müssen, ob die angelegten Sicherheitsmerkmale hier überhaupt gefordert waren.

Ja, unser Motto "Die Energie des Verstehens" gilt noch. Eben deshalb moniere ich hier so hartnäckig (und auch gegen Gegenwind), dass man Fragestellern nicht nur Konzepte vorsetzen sollte, die allgemein funktionieren, sondern, dass man sie dazu befähigen sollte, zu verstehen, wann was sinnvoll und anwendungsangepasst ist.

Ich bin mir nicht sicher, ob wir hier unter "Die Energie des Verstehens" noch das gleiche verstehen, wenn vorgefertigte Lösungen, die allgemein funktionieren, scheinbar einer anforderungsangepassten Lösung inklusive der Erklärung, warum das hier anwendungsangepasst ist, vorzuziehen sein soll.

Grüße,

RIDER

[JürgenB]

Hallo

… Eben deshalb moniere ich hier so hartnäckig (und auch gegen Gegenwind)

wozu ich z.Zt. weder Lust noch Zeit habe, daher mein Lob.

Ich finde, die hier vorgeschlagene Lösung geht für den Anwendungsfall „Spiel“ viel zu weit. Wenn man so etwas aus der Schublade ziehen kann, oder wenn man es geschenkt bekommt, warum nicht.

Allerdings muss ich hier jetzt auch diese recht sichere Lösung kritisieren: sie bietet genauso wenig Sicherheit, wie mein Vorschlag mit den "geheimen Dateinamen", wenn jemand das Passwort ausspäht oder verrät. Hier wäre dann wohl eine „Zweifaktor Authentisierung“ erforderlich, mit Anmeldung, Registrierung der Handynummer für eine Einmal-TAN, etc.. Will man das?

Gruß
Jürgen

[TS]

Hello,

… Eben deshalb moniere ich hier so hartnäckig (und auch gegen Gegenwind)

wozu ich z.Zt. weder Lust noch Zeit habe, daher mein Lob.

Ich finde, die hier vorgeschlagene Lösung geht für den Anwendungsfall „Spiel“ viel zu weit. Wenn man so etwas aus der Schublade ziehen kann, oder wenn man es geschenkt bekommt, warum nicht.

Allerdings muss ich hier jetzt auch diese recht sichere Lösung kritisieren: sie bietet genauso wenig Sicherheit, wie mein Vorschlag mit den "geheimen Dateinamen", wenn jemand das Passwort ausspäht oder verrät. Hier wäre dann wohl eine „Zweifaktor Authentisierung“ erforderlich, mit Anmeldung, Registrierung der Handynummer für eine Einmal-TAN, etc.. Will man das?

Es ist schade, dass Janosch und Du die Anforderungen des OP überhaupt nicht berücksichtigen wollt. Er hat ausdrücklich nach einer Möglichkeit der Authorisierung ohne Authentifizierung gefragt. Ein "geheimer Dateiname" ist aber keine gültige Authorisierung, sondern nur "Safety by Obscurity". Warum sich das schon auf der technischen Ebene verbietet, hat 1unitedpower ausführlich beschrieben!

"Safety" by Obscurity # Security!  

Dass eine "One Credential Authorization" auf der menschlichen Ebene Probleme geben kann, ist vollkommen klar. Das kann aber eine "Two Credentials Solution" auch noch. Solange man Tokens (Username, Passwort, Sessionkey, ...) weitergeben kann, ist dies ebenfalls keine "sichere Lösung". Schließlich wird der Username in den allermeisten Systemen immer noch sichtbar eingegeben. Der stellt also schon mal keinen Sicherheitsfaktor dar. Ganz im Gegenteil: Wenn ich jemanden ärgern will, uns seine Kontonummer kenne, dann kann ich ihn bei den meisten Bankingsystemen für mindestens 24 Stunden aus seinem Banking aussperren, indem ich einfach mehrmals versuche, mich unter seinem Namen/seiner Kontonummer mit falschem Passwort anzumelden...

Ihr Beide bringt hier einfach euer Bauchgefühl und die technisch anerkannten Regeln durcheinander!

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

[...] ist dies ebenfalls keine "sichere Lösung".

Wer was von IT-Sicherheit versteht, weiß, dass Sicherheit in der Informationstechnologie nie ein absoluter Wert ist, sondern stets relativ zu den jeweils abgedeckten Angriffsvektoren steht.

Eine „sichere Lösung“ zu nennen, die nicht auf die Anforderungen des konkreten Sachverhalts eingeht, sondern stattdessen willkürlich ein Level anzusetzen, das Sicherheitsmerkmale für einen angenommenen, allgemeinen Fall, erfüllt, ist für mich im Sinne der IT-Sicherheit nicht seriös.

Man muss hier, um eine im Sinne des Anwendungsfalls sichere Lösung zu finden, erstmal da ansetzen, dass man sich anschaut, gegen welche Form von Angriffen das System gesichert sein soll, und dann anhand dieser Überlegung die gewünschten Maßnahmen ermitteln.

Für ein Onlinebanking-System oder den Zugriff auf hochgeheime Daten sind die von dir vorgeschlagenen Maßnahmen weit davon entfernt, „sicher“ zu sein, weil in diesem Anwendungsfall sehr viel komplexere Angriffsvektoren mit einbezogen werden müssen.

Für viele Systeme, die mittelmäßig sensible Daten bzw. Möglichkeiten beinhalten, sind die von dir und @1unitedpower vorgeschlagenen Maßnahmen anzuraten.

Für ein Spiel, bei dem die Teilnehmer Regeln folgen und der Anschein von Sicherheit vollkommen ausreicht, um den Spielspaß zu garantieren, genügt schon ein ganz banales, im Klartext im Quelltext der Seite stehendes Passwort, da es völlig egal ist, ob man mit entsprechendem Aufwand „einbrechen“ kann. Das, wogegen man sich bei einem Spiel mit einer Passworteingabe „sichern“ will, ist einfach nur, dass die Spieler nicht direkt auf die Seite kommen, sondern das Passwort im Lauf des Spiels erst herausfinden müssen. Ob man das Passwort theoretisch umgehen oder die Seite knacken könnte ist vollkommen egal.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Ihr Beide bringt hier einfach euer Bauchgefühl und die technisch anerkannten Regeln durcheinander!

Ich habe im vergangenen Wintersemester an der Universität Ulm die Wahlveranstaltung „Sicherheit in IT-Systemen“ mit 6 ECTS-Leistungspunkten belegt und nach schriftlicher Prüfung mit einem respektablen Ergebnis von 1,7 abgeschlossen.

Ich denke, ich kann mein Bauchgefühl und meine sachlich fundierte Einschätzung zu Fragen der IT-Sicherheit durchaus auseinanderhalten.

@JürgenB würde ich übrigens Ähnliches unterstellen.

Grüße,

RIDER

[1unitedpower]

es handelt sich um ein Spiel, nicht um Homebanking.

Und eine gute Gelegenheit, um etwas über den sicheren Umgang mit Passwörtern dazuzulernen. Wenn das Passwort in der URL steht, wird es von den meisten Browsern bei der Navigation auf andere Seiten in den HTTP-Kopfdaten als Referrer übertragen und gerät so an die Öffentlichkeit.

[JürgenB]

Hallo,

es handelt sich um ein Spiel, nicht um Homebanking.

Und eine gute Gelegenheit, um etwas über den sicheren Umgang mit Passwörtern dazuzulernen.

wenn einem die Vorbereitung des Spiels dazu Zeit lässt, warum nicht.

Wenn das Passwort in der URL steht, wird es von den meisten Browsern bei der Navigation auf andere Seiten in den HTTP-Kopfdaten als Referrer übertragen und gerät so an die Öffentlichkeit.

warum soll von der "Preisseite" aus irgendwo hin verlinkt werden?

Gruß
Jürgen

[1unitedpower]

warum soll von der "Preisseite" aus irgendwo hin verlinkt werden?

Gegenfrage: Warum willst du die Preisseite so einschränken, dass sie nicht ins Netz verlinken darf? Verlinkungen sind das A und O des WWW.

Davon abgesehen obliegt es gar nicht der Kontrolle des Seitenautors: ein Browser-Plugin kann auch Links erzeugen und das Passwort kompromitieren.

[Tazzi]

Vielen Dank erstmal.

Also ich verstehe nur n bisschen was von HTML. Meine aktiven HTML Zeiten sind lange vorbei, daher hab ich viel vergessen.

Die Koordinaten, die dann auf der Seite nach dem Passwort angezeigt werden, führen die User dann zum Schatz. Daher sind es keine hoch geheimen Daten. Sie sollten dennoch weder von Google noch von jedem x beliebigen Laien zu einfach ohne Passwort zu sehen sein.

Ihr seht, ich brauche nichts für Knox mäßiges.. eher so Kindertresor

Weiss nur eben nicht wie..

[TS]

Hello,

Die Koordinaten, die dann auf der Seite nach dem Passwort angezeigt werden, führen die User dann zum Schatz. Daher sind es keine hoch geheimen Daten. Sie sollten dennoch weder von Google noch von jedem x beliebigen Laien zu einfach ohne Passwort zu sehen sein.

Ihr seht, ich brauche nichts für Knox mäßiges.. eher so Kindertresor

Bau Dir eine "Login-Seite" mit einem Formular, das auf sich selber postet. Starte eine Session. Wenn das eingetragene Passwort stimmt, schreibst Du die Logintime in die Session und leitest Du mit einem header()-Statement auf die "geschützte Seite" weiter. In einer Session setzt Du z. B. ein:

$_SESSION['logintime'] = time();  

In der anderen Seite prüfst Du gleich als erstes, ob in der Session

$time = time();
if (isset($_SESSION['logintime']) && ($_SESSION['logintime'] - $time < 360))
{
   $_SESSION['logintime'] = $time;  ## Nachtriggern
}
else
{
   header('/login.php');
   exit;
}

### HTML-Seite anzeigen

### hier dann eventHTML-Formular für Logout anzeigen

### Ende

Liebe Grüße
Tom S.

[Tazzi]

Hab nun endlich n Schnipsel gefunden, der funktioniert. Zumindest der einloggen Teil. Wo muss ich da den Link auf die gccoords.html machen, damit danach dort hin geleitet wird?

<?php
# Hier kann man das Passwort ändern
$passwort = "lassmichrein";

if (isset($_POST["go"])) {
 if ($_POST["name"] == $passwort) {
?>
<!-- hier könnt Ihr noch weiteren Text, Links, Bilder oder sonst etwas einbauen -->
<p>Dieser Text wird bei einem richtigen Passwort angezeigt.</p>

<?php
 }
 else {
  # Meldung bei einem falschen Passwort
 echo '<p><b><font color="red">Das Passwort ist falsch!</font></b><br><br>';
 echo '<a href="index.php">zur erneuten Eingabe</a></p>';
 }
}
else
{
?>

<!-- Hier wird das Passwort gesendet -->
<form action="index.php" method="post">
  <input type="Password" required placeholder="Passwort eingeben" name="name">
  <input type="Submit" name="go" value="Login">
</form>

<?php
}
?>

[TS]

Hello,

leitest Du mit einem header()-Statement auf die "geschützte Seite" weiter. In einer Session setzt Du z. B. ein:

$_SESSION['logintime'] = time();  

In der anderen Seite prüfst Du gleich als erstes, ob in der Session

Und hier musste die Differenz selbstverständlich umgekehrt gebildet werden:

$time = time();
if (isset($_SESSION['logintime']) && (($time - $_SESSION['logintime']) < 360))
{
   $_SESSION['logintime'] = $time;  ## Nachtriggern
}
else
{
   header('/login.php');
   exit;
}
 
### HTML-Seite anzeigen

### hier dann eventHTML-Formular für Logout anzeigen

### Ende

Liebe Grüße
Tom S.

Liebe Grüße
Tom S.

[Tazzi]

Sorry.. ich kann dir nicht folgen. :( Wo genau muss ich was eintragen?

So sieht das jetzt bei mir aus:

<html>
....... 
<BODY background="gc.jpg" bgproperties="repeat" bgcolor="#000000" text="#fff">


<br>
<br>
<br>
<br>
<br>


		
<div align="center">
<?php
# Hier kann man das Passwort ändern
$passwort = "blabla";

if (isset($_POST["go"])) {
 if ($_POST["name"] == $passwort) {
?>
<!-- hier könnt Ihr noch weiteren Text, Links, Bilder oder sonst etwas einbauen -->
<p>1.2.3.66.7</p>

<?php
 }
 else {
  # Meldung bei einem falschen Passwort
 echo '<p><b><font color="red">Leider falsch, versuch es erneut. / Definitely wrong, try again.</font></b><br><br>';
 echo '<a href="index.php">Nächster Versuch / Next try</a></p>';
 }
}
else
{
?>

<!-- Hier wird das Passwort gesendet -->
<form action="index.php" method="post">
  <input type="Password" required placeholder="Lösungswort / searched word" name="name">
  <input type="Submit" name="go" value="Senden/Sent">
</form>

<?php
}
?>
</div>
</BODY>
</HTML>

[TS]

Hello,

es gibt unterschiedliche Wege zum Ziel ;-)

Bau mal als erstes eine Seite "login.php", in der dein Login-Formular enthalten ist. Und bemühe dich dabei möglichst, HTML und PHP so gut es geht zu trennen.

Die Zugangsdaten

<?php   ### .htlogindata.php ### utf-8 ### ÄÖÜäöü

define('PASSWORD', 'streng Geheim');

?>

Das Login-Formular

<?php   ### login.php ### utf-8 ### ÄÖÜäöü

header('Content-Type: text/html; Charset=utf-8');
mb_internal_encoding('UTF-8');
session_start();

## Password-Konstante laden
require_once('.htlogindata.php');
$message = 'Abgemeldet';

if (isset($_POST['btn']['logout']))
{
    $_SESSION['logintime'] = false;
}
elseif (isset($_POST['btn']['login']))
{
    if (isset($_POST['data']['password']))
    {
        ## eventuell führende und anhängende Whitespaces wegtrimmen...
        if (PASSWORD ==  trim($_POST['data']['password']))
        {
            ### Login-Zeitpunkt in der Session merken
            $_SESSION['logintime'] = time();
            
            ### Weiterleiten zur geschützten Seite
            header('Location: myProtectedSite.php');
            exit; 
        }    
        else
        {
            $message = 'Passwort ist falsch. Bitte wiederholen';
            ### hier Logging einbauen für Fehlversuche
            #error_log( ... );
        }    
    }
}
else
{
    $message = 'Bitte Passwort eingeben';
}    
###############################################################################
# html output
###############################################################################
?>
<html>
    <head>
        <title>Passworteingabe</title>
    </head>
    <body>
        <p><?php echo htmlspecialchars($message); ?></p>
        <form action="login.php" method="post">
            <p><input type="password" name="data[password]"></p>
            <p><button type="submit" name="btn[login]">Anmelden</button></p>
        </form>
    </body>
</html>    

Die Seite, die nur mit Passwort benutzt werden darf

<?php   ### myProtectedSite.php ### utf-8 ### ÄÖÜäöü

header('Content-Type: text/html; Charset=utf-8');
mb_internal_encoding('UTF-8');
session_start();
$time = time();

if (isset($_SESSION['logintime']) && (($time - $_SESSION['logintime']) < 360))
{
   $_SESSION['logintime'] = $time;  ## Nachtriggern
}
else
{
   header('Location: login.php');
   exit;
}

###############################################################################
# html output
###############################################################################
?>
<html>
    <head>
        <title>Meine geheime Seite</title>
    </head>
    <body>
     	<h1>Geheime Hinweise</h1>

		<h2>Logout:</h2>
		<form action="login.php" method="post">
		    <button type="submit" name="btn[logout]">Wieder Abmelden</button>
		</form>

		<h2>Geodaten</h2>
		<p>Hier steht das nächste Ziel für das Spiel:</p>  
    	<div> Blah Geodaten Blubb </div>
      <div> und noch mehr BlahBlah </div>
	</body>
<html>	

Das ist jetzt ein minimalistisches Beispiel (getestet).
HTML bitte selber hübsch machen mit CSS!

Wenn Du die Möglichkeit dazu hast, sollte die Datei mit dem Passwort außerhalb der Document Root stehen. Dann muss sie aber auch entsprechend referenziert werden...

Liebe Grüße
Tom S.

[Tazzi]

Vielen Dank! Mit einigen optischen Anpassungen hab ich die Seite nun fertig :)

[Rolf B]

Hallo Tazzi,

lese den Thread erst jetzt... Warum eigentlich 2 Seiten? Warum nicht einfach nur eine, mit Post auf sich selbst.

Bei einem GET Request oder leerem Passwort zeigt sie das Passworteingabefeld.

Wenn das richtige Passwort gePOSTet wird, dann zeigt die Seite die Lösung an.

Und wird das falsche Passwort gepostet, zeigt sie auch Koordinaten an. Weißes Haus, Kreml, Mitte der Sahara - vieles ist möglich. Wer nicht komplett vernagelt ist, dürfte den Scherz erkennen ohne zum Ziel zu reisen :)

Rolf

[TS]

Hello,

Hallo Tazzi,

lese den Thread erst jetzt... Warum eigentlich 2 Seiten? Warum nicht einfach nur eine, mit Post auf sich selbst.

höhöhö
Du hast dir gerade ein <I> eingehandelt :-)

Machst Du bitte ein lauffähiges Muster fertig?

Liebe Grüße
Tom S.

[Rolf B]

Hallo TS,

och - das bleibt dem Anwender als leichte Übung überlassen. 😉
Affenformulare gibt's genug als Vorlage.

Rolf

[1unitedpower]

define('PASSWORD', 'streng Geheim');

Passwörter als Klartext zu hinterlegen ist keine gute Idee. Besser man speichert nur einen gesalzenen Hash. Auf Linux-Systemen kann man sich mit dem folgenden Bash-Skript so einen Hash generieren lassen:

php -r 'echo "Passwort:"; system("stty -echo"); $password = rtrim(fgets(STDIN),"\n"); system("stty echo"); $hash = password_hash($password, PASSWORD_DEFAULT); echo $hash;' 

Hier die Erläuterung:

php -r führt den nachfolgenden PHP-Code aus.

echo "Passwort:"; // Fordert den Benutzer auf sein Passwort einzugeben
system("stty -echo"); // Deaktiviert die Bildschirmausgabe und verhindert, dass das Passwort in der Bash-History auftaucht
$password = rtrim(fgets(STDIN),"\n"); // Liest das Passwort ein
system("stty echo"); // Reaktiviert die Bildschirmausgabe von Zeichen
$hash = password_hash($password, PASSWORD_DEFAULT); // Erzeugt den gesalzenen Passwort-Hash
echo $hash; // Gibt den neu generierten Hash aus

ACHTUNG: Bei Windows funktioniert das Unterdrücken der Ausgabe wie oben nicht.

Beispielausgabe: $2y$10$ysZS.7iJvmEantAioBKHK.CJ.jFRJGkzcRV5v.n0Zl1gZhc1YJ.ay

Außerdem will man solche Konfigurations-Daten für gewöhnlich nicht im Quelltext stehen haben, das erschwert unter anderem die Versionierung und das Deployment (Hintergrund) und macht es unsicherer. Ein besserer Speicherort dafür sind Umgebungsvariablen, wenn man behutsam damit umgeht. Damien Alexandre gibt dazu ein paar Tipps.

Bei Apache-Webservern kann man mit der SetEnv-Direktive Umgebungsvariablen setzen.

SetEnv APP_PASSWORD_HASH $2y$10$ysZS.7iJvmEantAioBKHK.CJ.jFRJGkzcRV5v.n0Zl1gZhc1YJ.ay

In PHP kann man die Umgebungsvariable mit getenv auslesen und mit password_verify auf sichere Weise mit der Benutzereingabe vergleichen:

$password = $_POST['password'];
$hash = getenv('APP_PASSWORD_HASH');
$isPasswordCorrect = password_verify($password, $hash);

[pl]

Credentials in Umgebungsvariablen setzen!? Das ist nicht dein Ernst oder!? Noch einmal zur Erinnerung: Die Serverumgebung ist Bestandteil der CGI Schnittstelle nach CGI/1.1 und dient dazu, Requestparameter an nachgelagerte Prozesse zu kommunizieren.

D.h., eine Konfiguration gleich welcher Art hat in der Serverumgebung nichts verloren. Das kannst Du vielleicht im stillen Kämmerlein mal testen aber nicht hier als Empfehlung durchreichen. MfG

[1unitedpower]

Credentials in Umgebungsvariablen setzen!? Das ist nicht dein Ernst oder!? Noch einmal zur Erinnerung: Die Serverumgebung ist Bestandteil der CGI Schnittstelle nach CGI/1.1 und dient dazu, Requestparameter an nachgelagerte Prozesse zu kommunizieren.

Richtig, so gelangen Umgebungsvariablen vom Webserver-Prozess an den PHP-Prozess. Das ist ja gewünscht. Worauf du vermutlich hinweisen willst, ist dass die Umgebung auch an weitere Kindprozesse durchgereicht werden könnte, die von PHP aus gestartet werden. Bei Apache-Webservern muss man solchen Enkelprozessen deshalb die Privilegien mit env -i ausdrücklich entziehen. Bei nginx-Webservern ist das einfacherer, der entzieht allen Enkelprozessen automatisch die Umgebungsvariablen. Das steht auch in den Tipps zu Umgebungsvariablen, die ich hier verlinkt habe.

D.h., eine Konfiguration gleich welcher Art hat in der Serverumgebung nichts verloren. Das kannst Du vielleicht im stillen Kämmerlein mal testen aber nicht hier als Empfehlung durchreichen.

Doch, das ist der Stand der Technik und die sicherste Variante Konfigurationen zwischen Deploys zu trennen. Die Richtlinien der Twelve-Factor-App, die ich ebenfalls verlinkt habe, haben dazu auch extra einen Abschnitt.

[pl]

hi,

Doch, das ist der Stand der Technik und die sicherste Variante Konfigurationen zwischen Deploys zu trennen. Die Richtlinien der Twelve-Factor-App, die ich ebenfalls verlinkt habe, haben dazu auch extra einen Abschnitt.

Wenn ein versehentliches Einchecken von Konfigurationsdateien in eine Repository das einzige Argument ist: Dem kann man auch anders begegnen, z.b. in der Anwendung zur Versionskontrolle selbst (→SVN). Außerdem abstrahieren DALs auch andere Pfade die nicht ins eigenen Dateisystem zeigen wir z.B. UNC oder URI.

MfG

[pl]

hi,

Doch, das ist der Stand der Technik und die sicherste Variante Konfigurationen zwischen Deploys zu trennen. Die Richtlinien der Twelve-Factor-App, die ich ebenfalls verlinkt habe, haben dazu auch extra einen Abschnitt.

Wenn ein versehentliches Einchecken von Konfigurationsdateien in eine Repository das einzige Argument ist: Dem kann man auch anders begegnen, z.b. in der Anwendung zur Versionskontrolle selbst (→SVN). Außerdem abstrahieren DALs auch andere Pfade die nicht ins eigenen Dateisystem zeigen wir z.B. UNC oder URI.

Ergänzung der Vollständigkeit halber: In meinem FW haben die Quelldateien zur Konfiguration ein eigenes Repository, was vom Repository der Software vollständig getrennt ist. Das Erstellen der Konfiguration ist also Bestandteil des Deployments wobei alle Konfigurationsparameter in einer Datei zusammengefasst sind. Beim jedem Deploy wird also diese Datei neu gebildet und nach dem Neustart des Webservers befindet sich die ganze Konfiguration komplett im Hauptspeicher für den wahlfreien Zugriff (Random Access). Die Datei dient also einmal dem Transport und zum Anderen dem Webserver als Backup falls dieser neu gestartet werden muss. Optional kann dieses Backup auch in eine DB gelegt werden.

Konfiguration und Software definieren also zwei verschiedene und voneinander unabhängige Deployments und haben voneinander getrennte Repositories, das ist die Trennung. Das Laden meiner Konfiguration in den Hauptspeicher hat nicht die Trennung von der Versionskontrolle zum Ziel sondern den wahlfreien Zugriff. Die Trennung von der Versionskontrolle der Software erfolgt wie beschrieben an anderer Stelle.

MfG

[1unitedpower]

Wenn ein versehentliches Einchecken von Konfigurationsdateien in eine Repository das einzige Argument ist: Dem kann man auch anders begegnen, z.b. in der Anwendung zur Versionskontrolle selbst (→SVN).

Versionskontrollsysteme bieten in aller Regel die Möglichkeit Dateien auf eine schwarze Liste zu setzen, die dann nicht versioniert werden. In git wäre das die .gitignore-Datei in SVN gibt es diverse Möglichkeiten. Das kann und sollte man auch tun, wenn man sich dafür entscheidet seine Deploy-spezfische Konfiguration in Dateien zu verwalten, die im Dateisystem zusammen mit dem Code-Repository leben. Und man muss es sogar tun, wenn das Code-Repostory öffentlich ist. Sauberer ist meiner Meinung nach der Ansatz der 12-Factor-App bei dem man Code-Repository und Deploy-spezfische Konfiguration vollständig voneinander trennt. Wenn solche Konfigurations-Daten gar nicht im Dateisystem zusammen mit dem Code-Repository leben, dann erleichtert das ja die Versionskontrolle und das Deployment.

Außerdem abstrahieren DALs auch andere Pfade die nicht ins eigenen Dateisystem zeigen wir z.B. UNC oder URI.

Die kann man ebenfalls in Umgebungsvariablen packen und so sauber vom Code-Repository trennen.

[pl]

Letztendlich liegt ja die Serverumgebung auch im Speicher: Für den wahlfreien Zugriff. Und genau das muss eine Konfiguration auch. Der Unterschied ist jedoch, dass auf die Serverumgebung jede Anwendung nach CGI/1.1 zugreifen kann, auf die Konfiguration aber nur die eigene Anwendung.

Und da jeder RAM sein Gedächtnis verliert wenn der Srom weg ist, muss auch Deine Konfiguration irgendwo persistent sein. Somit kann ein Laden Deiner Konfiguration in den Hauptspeicher gar nicht die Lösung zur Trennung vom Repository sein, sowas in die Dokumentation zu schreiben ist irreführend. MfG

[1unitedpower]

Letztendlich liegt ja die Serverumgebung auch im Speicher: Für den wahlfreien Zugriff. Und genau das muss eine Konfiguration auch. Der Unterschied ist jedoch, dass auf die Serverumgebung jede Anwendung nach CGI/1.1 zugreifen kann, auf die Konfiguration aber nur die eigene Anwendung.

Du versuchst Probleme auf der Anwendungsschicht zu lösen, die in der darunter liegenden Schicht bereits gelöst sind. Wieso willst du überhaupt mehrere Anwendungen in der selben Serverumgebung betreiben? Das ist zum Scheitern verurteilt. Verschiedene Anwendungen erfordern verschiedene Priveligien, unterschiedliche Zuteilung von Rechenressourcen, unterschiedliche Software-Abhängigkeiten und isolierte Umgebungen, damit sie sich nicht gegenseitig behindern, blockieren und sicherhetiskritsche Einstellungen leaken. Dinge, die man in den Virtual-Host-Konfigurationen des Apache-Server löst.

Und da jeder RAM sein Gedächtnis verliert wenn der Srom weg ist, muss auch Deine Konfiguration irgendwo persistent sein. Somit kann ein Laden Deiner Konfiguration in den Hauptspeicher gar nicht die Lösung zur Trennung vom Repository sein, sowas in die Dokumentation zu schreiben ist irreführend.

Mein Vorschlag ist, die Konfiguration im Apache Server bzw. Virtual Host zu speichern. Dort liegt sie getrennt vom Code-Repository der jeweiligen Anwendung.

[pl]

hi,

Mein Vorschlag ist, die Konfiguration im Apache Server bzw. Virtual Host zu speichern. Dort liegt sie getrennt vom Code-Repository der jeweiligen Anwendung.

Aha! Dann ist mein Vorschlag, das auch so in die Dokumentation reinzuscheiben.

Schöne Grüße.

[Christian Kruse]

Hallo pl,

Credentials in Umgebungsvariablen setzen!? Das ist nicht dein Ernst oder!? Noch einmal zur Erinnerung: Die Serverumgebung ist Bestandteil der CGI Schnittstelle nach CGI/1.1 und dient dazu, Requestparameter an nachgelagerte Prozesse zu kommunizieren.

Blödsinn. Erstens läuft PHP idR nicht als CGI (sondern als Modul oder FastCGI, und dort sind es bestenfalls dem Anschein nach noch Umgebungsvariablen) und zweitens definiert CGI nur ein paar spezifische Umgebungsvariablen, und nicht das vollständige Environment.

D.h., eine Konfiguration gleich welcher Art hat in der Serverumgebung nichts verloren.

Einzelne Werte der Konfiguration in Umgebungsvariablen zu packen ist gängige Praxis und state of the art.

LG,
CK

[pl]

Einzelne Werte der Konfiguration in Umgebungsvariablen zu packen ist gängige Praxis und state of the art.

Bedenke daß das globale Variablen sind. Für Programmierer die mit globalen Variablen kein Problem haben, mag das gängige Praxis sein. Ich gehöre nicht zu denen. MfG

[dedlfix]

Tach!

Einzelne Werte der Konfiguration in Umgebungsvariablen zu packen ist gängige Praxis und state of the art.

Bedenke daß das globale Variablen sind.

Nö, das sind im PHP-Script Einträge im Array $_SERVER.

dedlfix.

[TS]

Hello,

landen die Umgebungsvariablen nicht in $_ENV und tauchen dort auch nur auf, wenn man sie benutzt? Copy-on-use, oder wie das heißt?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

landen die Umgebungsvariablen nicht in $_ENV [...]?

Ja, da landen sie nicht. Es sei denn, man setzt sich ein zusätzliches E in variables_order. Das ist zwar der Default-Wert, aber nicht der empfohlene für Entwicklung und Produktivumgebung. In (F)CGI-Umgebungen landen sie jedoch auch in $_SERVER, weswegen man $_ENV da nicht benötigt.

dedlfix.

[pl]

Tach!

Einzelne Werte der Konfiguration in Umgebungsvariablen zu packen ist gängige Praxis und state of the art.

Bedenke daß das globale Variablen sind.

Nö, das sind im PHP-Script Einträge im Array $_SERVER.

Stimmt, $_SERVER ist ja gar nicht global sondern Superglobal da hast Du völlig recht.

MfG

[Mitleser]

Einzelne Werte der Konfiguration in Umgebungsvariablen zu packen ist gängige Praxis und state of the art.

Bedenke daß das globale Variablen sind. Für Programmierer die mit globalen Variablen kein Problem haben, mag das gängige Praxis sein. Ich gehöre nicht zu denen. MfG

Dazu habe ich eine Frage: wie ermittelst Du denn z.B. die Umgebungsvariable "HTTP_HOST"?

[pl]

Einzelne Werte der Konfiguration in Umgebungsvariablen zu packen ist gängige Praxis und state of the art.

Bedenke daß das globale Variablen sind. Für Programmierer die mit globalen Variablen kein Problem haben, mag das gängige Praxis sein. Ich gehöre nicht zu denen. MfG

Dazu habe ich eine Frage: wie ermittelst Du denn z.B. die Umgebungsvariable "HTTP_HOST"?

Indem ich den Standard CGI/1.1 benutze. Zum Thema objektorientierte Konfiguration in Perlscripts hab ich übrigens einen Artikel geschrieben.

Eine Konfiguration in den Hauptspeicher zu legen mit der Begründung daß sie damit nicht versehentlich im Repository einer Versionsverwaltung gespeichert wird ist jedenfalls der größte Schwachsinn aller Zeiten der mit je untergekommen ist.

Und was CGI/1.1 betrifft, gibt es auch, z.B. mit PSGI, Bestrebungen den Geltungsbereich der Variablen einzuschränken. MfG

[Mitleser]

Bedenke daß das globale Variablen sind. Für Programmierer die mit globalen Variablen kein Problem haben, mag das gängige Praxis sein. Ich gehöre nicht zu denen. MfG

Dazu habe ich eine Frage: wie ermittelst Du denn z.B. die Umgebungsvariable "HTTP_HOST"?

Indem ich den Standard CGI/1.1 benutze. Zum Thema objektorientierte Konfiguration in Perlscripts hab ich übrigens einen Artikel geschrieben.

Habe nur ganz kurz reingeschaut. Meine Frage nach HTTP_HOST wird in Deinem Artikel leider nicht erwähnt. Aber, Zitat: "$ARGV[0]". Das ist ein Zugriff auf eine globale Variable, wenn mich nicht alles täuscht.

[pl]

Bedenke daß das globale Variablen sind. Für Programmierer die mit globalen Variablen kein Problem haben, mag das gängige Praxis sein. Ich gehöre nicht zu denen. MfG

Dazu habe ich eine Frage: wie ermittelst Du denn z.B. die Umgebungsvariable "HTTP_HOST"?

Indem ich den Standard CGI/1.1 benutze. Zum Thema objektorientierte Konfiguration in Perlscripts hab ich übrigens einen Artikel geschrieben.

Habe nur ganz kurz reingeschaut. Meine Frage nach HTTP_HOST wird in Deinem Artikel leider nicht erwähnt.

Das ist ja auch nicht die Zweckbestimmung meines Artikels. In meinem Artikel geht es darum, wie man sich von globalen Variablen wegbewegen kann und was das für Vorteile bringt.

Aber, Zitat: "$ARGV[0]". Das ist ein Zugriff auf eine globale Variable, wenn mich nicht alles täuscht.

Ja, man kann auch den Geltungsbereich von globalen Variablen einschränken: Indem man den Zugriff auf diese Variablen zentralisiert und nicht über die gesamte Anwendung verteilt. Das gilt übrigens auch für die Verwendung von HTTP_HOST in meinem FW.

[Mitleser]

Ja, man kann auch den Geltungsbereich von globalen Variablen einschränken: Indem man den Zugriff auf diese Variablen zentralisiert und nicht über die gesamte Anwendung verteilt. Das gilt übrigens auch für die Verwendung von HTTP_HOST in meinem FW.

Wunderbar. Wo genau in diesem Thread wurde das Gegenteil postuliert?

[pl]

Ja, man kann auch den Geltungsbereich von globalen Variablen einschränken: Indem man den Zugriff auf diese Variablen zentralisiert und nicht über die gesamte Anwendung verteilt. Das gilt übrigens auch für die Verwendung von HTTP_HOST in meinem FW.

Wunderbar. Wo genau in diesem Thread wurde das Gegenteil postuliert?

Wenn das Setzen von Env Global-Variablen gar keinen oder nur einen einmaligen Zugriff zum Ziel hätte wäre es ja unsinnig. Da kann man sich den Umweg über die globale Variable auch sparen.

[Mitleser]

Ja, man kann auch den Geltungsbereich von globalen Variablen einschränken: Indem man den Zugriff auf diese Variablen zentralisiert und nicht über die gesamte Anwendung verteilt. Das gilt übrigens auch für die Verwendung von HTTP_HOST in meinem FW.

Wunderbar. Wo genau in diesem Thread wurde das Gegenteil postuliert?

Wenn das Setzen von Env Global-Variablen gar keinen oder nur einen einmaligen Zugriff zum Ziel hätte wäre es ja unsinnig. Da kann man sich den Umweg über die globale Variable auch sparen.

Verstehe ich nicht. Bleibe mal bei Deinem verlinkten Beispiel. Wo siehst Du in Deiner Argumentation den Unterschied von "Original":

"heatup => $ARGV[0] ? $ARGV[0] : 0"

zur Variante mittels Umgebungsvariable:

"heatup => $ENV['heatup'] ? $ENV['heatup'] : 0"

Ob und wie oft auf "heatup" dann letztlich zugegriffen wird, ist doch eine völlig andere Frage.

[pl]

Ob und wie oft auf "heatup" dann letztlich zugegriffen wird, ist doch eine völlig andere Frage.

Ja eben. heatup => $ARGV[0] ? $ARGV[0] : 0 wird einmal als Eigenschaft in die Instanz gesetzt zu dem Zeitpunkt an dem die Instanz erstellt wird.

Jeder weitere Zugriff auf diese Eignschaft ist dann unabhängig davon, ob sich $ARGV inzwischen geändert hat (was ja bei globalen Variablen sein kann). Wenn nach der Instanzerstellung eine Änderung gewünscht ist, wird diese nicht in $ARGV vorgenommen sondern in der eigenen Instanz. MfG

[Mitleser]

Vielen Dank, dass Du genau auf die entscheidende Frage geantwortet hast ;-) Wo liegt in Deiner Argmentation der Unterschied beider Varianten?

[pl]

Vielen Dank, dass Du genau auf die entscheidende Frage geantwortet hast ;-) Wo liegt in Deiner Argmentation der Unterschied beider Varianten?

Mal Anders formuliert: Zum Zeitpunkt der Initialisierung einer Instanzeigenschaft gibt es keinen Unterschied. Globale Variablen sind jedoch mit dem Problem behaftet, daß sie über den Verlauf einer Anwendung, also auch nach der Instanzerstellung einen anderen Wert annehmen können. Mit der einmaligen Initialisierung einer Eigenschaft der Klasseninstanz wird dieses Problem eleminiert, weil jeder weitere Zugriff nicht über die globale Variable erfolgt sondern über die eigene Eigenschaft.

[Christian Kruse]

Hallo pl,

Mit der einmaligen Initialisierung einer Eigenschaft der Klasseninstanz wird dieses Problem eleminiert, weil jeder weitere Zugriff nicht über die globale Variable erfolgt sondern über die eigene Eigenschaft.

Was du nicht verstanden zu haben scheinst: das wird auch so gehandhabt bei der Verwendung von Umgebungsvariablen. Niemand (nunja, vermutlich: fast niemand) ist so bescheuert und ruft überall, wo er einen Konfigurations-Wert braucht, immer die Umgebungsvariable ab. Das wird zentral in der Konfigurations-Abstraktion gehandhabt.

LG,
CK

[pl]

Hallo pl,

Mit der einmaligen Initialisierung einer Eigenschaft der Klasseninstanz wird dieses Problem eleminiert, weil jeder weitere Zugriff nicht über die globale Variable erfolgt sondern über die eigene Eigenschaft.

Was du nicht verstanden zu haben scheinst: das wird auch so gehandhabt bei der Verwendung von Umgebungsvariablen. Niemand (nunja, vermutlich: fast niemand) ist so bescheuert und ruft überall, wo er einen Konfigurations-Wert braucht, immer die Umgebungsvariable ab. Das wird zentral in der Konfigurations-Abstraktion gehandhabt.

Hab ich Dir ja auch geschrieben: Da kannst Du Dir den Umweg über Globale Variablen auch sparen. MfG

[Mitleser]

Hab ich Dir ja auch geschrieben: Da kannst Du Dir den Umweg über Globale Variablen auch sparen. MfG

Um Rekursion zu verstehen, muss man zunächst Rekursion verstehen!

Wie weit geht eigentlich die Nested-Ansicht? 😉

[pl]

Mir fällt dazu eher der Witz mit dem Blinden ein der einen Blondinenwitz erzählen will aber aufgrund seiner Behinderung nicht wissen kann, daß alle Zuhörer blond sind. Als er es dennoch rechtzeigig bemerkte, erzählt er den Witz nicht weil er keine Böcke hat, den jedem Einzelnen erklären zu müssen.

Schönes Wochenende.

[Tabellenkalk]

Hallo,

jedem Einzelnen erklären zu müssen.

das Tolle an einem Forum, so als Gegentum zur Email-Kommukation, ist, dass man eine Erklärung nur einmal schreibt, und diese dann alle am Forum Beteiligten lesen können…

Gruß
Kalk

[TS]

Hello,

jedem Einzelnen erklären zu müssen.

das Tolle an einem Forum, so als Gegentum zur Email-Kommukation, ist, dass man eine Erklärung nur einmal schreibt, und diese dann alle am Forum Beteiligten lesen können…

[...] könnten [...] :-(

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@Tabellenkalk

jedem Einzelnen erklären zu müssen.

das Tolle an einem Forum, so als Gegentum zur Email-Kommukation, ist, dass man eine Erklärung nur einmal schreibt, und diese dann alle am Forum Beteiligten lesen können…

Das ist doch bei Mailinglisten auch so‽ *duckundweg*

LLAP 🖖

[Christian Kruse]

Hallo pl,

Hab ich Dir ja auch geschrieben: Da kannst Du Dir den Umweg über Globale Variablen auch sparen. MfG

Ich glaube, du hast es immer noch nicht verstanden. Man verwendet Umgebungsvariablen, damit man die Konfiguration einer einzelnen Installation nicht im Repository hat. Denn dann hätte man ja bei jeder Installation lokale Änderungen im Repository. Das ist unpraktisch, kann zu Problemen führen und nervt. Stattdessen verwendet man Umgebungsvariablen, die dann in z.B. der Service-File gesetzt werden. Die SystemD-Unit-File für die Produktiv-Installation einer meiner Services etwa sieht so aus:

[Unit]
Description=Automatic Call Distribution
After=network.target

[Service]
Type=simple
User=acd
Group=web-services
Restart=on-failure
RestartSec=5
Environment=MIX_ENV=prod
Environment=LANG=en_US.UTF-8
Environment=PORT=4000
Environment=DB_HOST=localhost
Environment=DB_USER=acd
Environment=DB_NAME=acd_prod
WorkingDirectory=/opt/acd
ExecStart=/opt/acd/bin/acd foreground
ExecStop=/opt/acd/bin/acd stop

[Install]
WantedBy=multi-user.target

Damit weiss SystemD alles, was es wissen muss und ich habe keine Konfigurationsdaten in meinem Repo. Dieses Vorgehen unterscheidet sich von deinem CLI-Argumente-Vorgehen nicht wesentlich, ausser dass die Argumente in einem einfachen ps einsehbar sind, das Environment eines Prozesses aber nicht.

LG,
CK

[pl]

Hab ich Dir ja auch geschrieben: Da kannst Du Dir den Umweg über Globale Variablen auch sparen. MfG

Ich glaube, du hast es immer noch nicht verstanden. Man verwendet Umgebungsvariablen, damit man die Konfiguration einer einzelnen Installation nicht im Repository hat.

Umgebungsvariablen verwenden heißt, sich in Sachen Konfiguration vom Server abhängig zu machen. Zweckmäßiger ist es jedoch, gerade im shared hosting Segment, es genau umgekehrt zu tun, also auch das, was normalerweise in der Serverkonfiguration angesiedelt ist, zu einer Angelegenheit der eignen Konfiguration zu machen.

Konkretes Beispiel (und passend zu diesem Thread): Nicht der Webserver greift auf die Datei mit den Passwords, sondern die eigene Anwendung definiert eine eigene Schnittstelle zu dieser Datei. So kann man das mit dem Apache mitgelieferte Utility htpasswd nutzen zum Erstellen, Bearbeiten der Passwortdatei und diese Datei dann sowohl für Authorization Basic als auch für eigene Loginprozesse verwenden. Unabhängig davon kann man Passworte natürlich auch in einer DB hinterlegen.

Abstrakt: Der Webserver wird nur soweit konfiguriert um sämtliche weitere Konfigurationsparameter in einer eigenen Konfiguration ansiedeln zu können. Wenn ich z.b. in meinem FW eine AuhBasic brauche, kann ich die mit $self->auth() an jeder xBeliebigen Stelle in die Anwendung einbauen ohne daß ich hierzu eine .htaccess anpassen muss.

Was natürlich nicht heißt daß man auf Umgebungsvariablen völlig verzichten kann.

Und was draußen gerade Mode und gängige Praxis ist, lieber Christian, das heiß noch lange nicht daß es ebenso zweckmäßig ist, ganz im Gegenteil. Solange ich noch berufstätig war, habe ich Praktiken erlebt die man lieber nicht machen sollte. MfG

PS: Mein Beispiel analog zu Deinem betreff eines auf /index.html liegenden Webservice:

[/index.html]
auth=manager.realm
interface=webservice

deklariert die Paswortdatei namentlich und beim Request käme entweder Authorization Baisc ins Spiel über $self->auth() oder die Anwendung (interface=webservice) nutzt mit $self->checkpass() lediglich die Schnittstelle zur Datei deren Name in der Konfiguration deklariert ist.

Ansonsten laufen meine Webservices wie RPCs über dasselbe Framework wie jeder andere Request auch. D.h., daß da nichts zusätzliches installiert oder an der Serverkonfiguration angepasst werden muss. Für jede Domäne/Realm gibt es bei mir eine Konfigurationsdatei deren Einzelwerte der [default] Sektion gemäß OOP Maxime für jeden URL überschrieben werden können. Wenn da z.B. für MySQL der Name dbh=myweb notiert ist, kann für den speziellen URL /webalizer der Name mit dbh=logger anders festgelegt werden. Ein Aufruf von $self->dbh() stellt dann automatisch die Verbindung zur richtigen DB her und findet die Credentials in $self->{FILEDIR}/dbh.ini ganz von selbst.

Die Datei dbh.ini definiert den Schlüsselworten entsprechende Sektionen, [myweb], [shop] usw.

[Mitleser]

Umgebungsvariablen verwenden heißt, sich in Sachen Konfiguration vom Server abhängig zu machen. Zweckmäßiger ist es jedoch, gerade im shared hosting Segment, es genau umgekehrt zu tun, also auch das, was normalerweise in der Serverkonfiguration angesiedelt ist, zu einer Angelegenheit der eignen Konfiguration zu machen.

.htaccess. Mindestens eine RewriteRule wird man in den meisten Fällen sowieso schon notieren wollen. Dann sehe ich keinen Bruch mehr, dort auch Umgebungsvariablen zu setzen.

Der Rest ist mir entweder zu hoch oder er hat mit eigentlichen Frage nichts zu tun.

[pl]

Umgebungsvariablen verwenden heißt, sich in Sachen Konfiguration vom Server abhängig zu machen. Zweckmäßiger ist es jedoch, gerade im shared hosting Segment, es genau umgekehrt zu tun, also auch das, was normalerweise in der Serverkonfiguration angesiedelt ist, zu einer Angelegenheit der eignen Konfiguration zu machen.

.htaccess. Mindestens eine RewriteRule wird man in den meisten Fällen sowieso schon notieren wollen. Dann sehe ich keinen Bruch mehr, dort auch Umgebungsvariablen zu setzen.

Ich auch nicht.

Der Rest ist mir entweder zu hoch oder er hat mit eigentlichen Frage nichts zu tun.

Nun gut, wir setzen $ENV{HTTP_AUTHORIZATION} in die Umgebung damit wir das abfragen können, das klingt schon paradox. Aber genau diese Variable brauchen wir, damit wir alles Weitere was über AuthBasic läuft in einer eigenen Konfiguraion regeln können ohne daß wir dazu die .htaccess wieder anfassen müssen.

D.h., welche URLs einschließlich bestimmter Parameter eine AuthBasic brauchen und wo die Datei mit den Paswords dazu liegt, ist dann nicht mehr Sache der Serverkonfiguration. MfG

[Mitleser]

Nun gut, wir setzen $ENV{HTTP_AUTHORIZATION} in die Umgebung damit wir das abfragen können, das klingt schon paradox. Aber genau diese Variable brauchen wir, damit wir alles Weitere was über AuthBasic läuft in einer eigenen Konfiguraion regeln können ohne daß wir dazu die .htaccess wieder anfassen müssen.

Ich kann Dir immer noch nicht ganz folgen, ist aber auch egal. Niemand hat behauptet, dass man alles nur erdenkliche in Umgebungsvariablen werfen sollte. Im Gegenteil wurde frühzeitig in dem Thread darauf hingewiesen, dass dies nicht sinnvoll ist, sondern auf den jeweiligen Fall passen sollte.

Jetzt konstruierst Du womöglich irgendeinen Fall, wo es nicht sinnvoll ist. Herzlichen Glühstrumpf!

[pl]

Ich bin ja nicht nur wegen dem Wetter hier, auch die Schwerkraft spielt eine gewisse Rolle. Aber schon interessant, was die Anderen so machen und wie sie es machen. Man sollte ein Buch darüber schreiben. MfG

[Christian Kruse]

Hallo pl,

deine Ergüsse sind repetitiv. Du wiederholst nur, was du vorher schon schriebst. Ich habe keine Lust das alles nochmal durchzukauen.

Und was draußen gerade Mode und gängige Praxis ist, lieber Christian, das heiß noch lange nicht daß es ebenso zweckmäßig ist, ganz im Gegenteil.

„Ich bin kein Klugscheisser, ich weiss es wirklich besser!”

LG,
CK

[1unitedpower]

Jeder weitere Zugriff auf diese Eignschaft ist dann unabhängig davon, ob sich $ARGV inzwischen geändert hat (was ja bei globalen Variablen sein kann). Wenn nach der Instanzerstellung eine Änderung gewünscht ist, wird diese nicht in $ARGV vorgenommen sondern in der eigenen Instanz.

Ich bleibe mal bei PHP, dort würde ich einen schreibenden Zugriff auf $_SERVER als ein Fehlverhalten des Programms einstufen, eine Kondition die niemals eintreten sollte, also ein Bug. Nun ist es leider so, dass PHP es prinzipiell nicht verbietet $_SERVER zu beschreiben. Dagegen kann man sich mit einem Acceptance-Test schützen.

[pl]

Jeder weitere Zugriff auf diese Eignschaft ist dann unabhängig davon, ob sich $ARGV inzwischen geändert hat (was ja bei globalen Variablen sein kann). Wenn nach der Instanzerstellung eine Änderung gewünscht ist, wird diese nicht in $ARGV vorgenommen sondern in der eigenen Instanz.

Ich bleibe mal bei PHP, dort würde ich einen schreibenden Zugriff auf $_SERVER als ein Fehlverhalten des Programms einstufen, eine Kondition die niemals eintreten sollte, also ein Bug. Nun ist es leider so, dass PHP es prinzipiell nicht verbietet $_SERVER zu beschreiben. Dagegen kann man sich mit einem Acceptance-Test schützen.

Objektorientierte Programmierung ist die Antwort und gerade da hat PHP das was Perl nicht hat: Private Eigenschaften und Methoden. MfG

[TS]

Hello,

[...] Acceptance-Test [...]

Könntest Du bitte mal für Forums-Wähler äh normale deutsche Forums-Teilnehmer erklären, was das bedeutet? :-)

Liebe Grüße
Tom S.

[1unitedpower]

[...] Acceptance-Test [...]

Könntest Du bitte mal für Forums-Wähler äh normale deutsche Forums-Teilnehmer erklären, was das bedeutet? :-)

Ich kann erklären, was ich gemeint habe, die genaue Bedeutung variiert in der Literatur sehr stark und hängt auch maßgeblich vom Kontext ab. Ein (Software-)Test ist ganz allgemein die Ausführung eines Programms mit der Absicht Fehler zu finden. Ein Regressions-Test ist ein programmierter Test, der immer wieder automatisch abgespielt werden kann. Man unterscheidet häufig zwischen drei Klassen von Regeressions-Tests: Unit-Tests, Integration-Tests und Acceptance-Tests. Ein Unit-Test überprüft genau ein Modul. Ein Integrations-Test überprüft das Zusammenwirken von Modulen, die direkt voneinander abhängen. Und der Acceptance-Test schließlich überprüft das Zusammenspiel aller Module, die in einer Software mitwirken, sozusagen das Gesamtpaket.

[TS]

Hello,

Danke

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Passwörter als Klartext zu hinterlegen ist keine gute Idee. Besser man speichert nur einen gesalzenen Hash.

Man salzt doch Hashes vor allem dafür, damit in einer Passwortdatenbank gleich gewählte Passwörter eben nicht den gleichen Hash bekommen.

Die Anforderung war hier aber nicht die Erstellung mehrerer Logins, die in einer entsprechenden Passwortdatenbank vorgehalten werden, sondern ein einzelnes Passwort, ohne Benutzername.

Man kann den Hash also salzen, hat aber in dem Anforderungsfall keinerlei Sicherheits-Plus dadurch. Natürlich sollte man Passwörter als gesalzenen Hash speichern, nur war hier die Rede von ein (und nur ein) Passwort.

So viel zum Salz im Hash bei diesem Anwendungsfall.

Das Speichern von Passwort-Hashes bietet vor allem zwei Sicherheitsvorteile:

1.: Ein externer Angreifer kann durch Abgreifen des gespeicherten Datenbestands die Passwörter nicht in einer Form bekommen, mit der er sich einloggen kann

2.: Ein interner Mitarbeiter kann die Passwörter nicht im Klartext aus dem System bekommen und sich damit woanders einloggen, falls der Benutzer sein Passwort in mehreren Systemen benutzt.

Vorteil 1 bleibt auch in diesem Anwendungsfall bestehen. Vorteil 2 wird in diesem Anwendungsfall völlig nutzlos, da das Passwort nicht personalisiert ist und sowieso von einem Internen vergeben wird; und da es sich hier um die Preisseite handelt sind Menschen mit Zugriff auf das System sowieso von der Teilnahme ausgeschlossen.

Das Hashen ist also durchaus durch Systemsicherheit begründbar, falls ein Sicherheitsbedürfnis gegenüber externen Angreifern, die die Datenbank gehackt haben, überhaupt besteht.

---

Wir wissen beide, dass du im Allgemeinfall Recht hast. Aber ich finds schwierig, immer mit allgemeingültigen Antworten aufzuwarten, die die Bedürfnisse des Anwendungsfalls nicht mit einbeziehen.

Grüße,

RIDER

[1unitedpower]

Man salzt doch Hashes vor allem dafür, damit in einer Passwortdatenbank gleich gewählte Passwörter eben nicht den gleichen Hash bekommen.

Das ist ein wesentlicher Punkt, weswegen man Hashes salzt. Es gibt aber noch einen weiteren: Für ungesalzene Hashes kursieren Regenbogentabellen, mit deren Hilfe man kostengünstig Kollisionen berechnen kann. Wenn der Hash also irgendwie in die falschen Hände gerät, kann ein Angreifer den Hash in einer Regenbogentabelle suchen und so an das Passwort gelangen. Ist der Hash aber gesalzen, müsste der Angreifer erst eine neue Regenbogentabelle erzeugen, das ist (komplexitätstheoretisch) ein deutlich schwierigeres Problem.

Wir wissen beide, dass du im Allgemeinfall Recht hast. Aber ich finds schwierig, immer mit allgemeingültigen Antworten aufzuwarten, die die Bedürfnisse des Anwendungsfalls nicht mit einbeziehen.

Da geb ich dir grundsätzlich Recht. Meine Intention ist auch nicht, dass der TO sich erst einem Kryptographie-Studium widmet, bevor er sein Spiel in die Tat umsetzt. Meine Hoffnung ist, dass sich Mitleser(innen), wenn sie je in die Situation geraten, ein sicheres Authentifizierungsystem implementieren zu müssen, daran erinnern, dass es für den Ernstfall deutlich mehr zu berücksichtigen gilt. Ich will für die Komplexität von sicherheitskritischen Software-Systemen sensibilisieren. Insofern ist es meinem Ziel sogar dienlich, wenn ein(e) Leser(in) aus seiner/ihrer Komfortzone gerissen wird und sich von der Materie überfordert fühlt. Das mag ein unangehmes Gefühl in ihm oder ihr auslösen, aber es hat dennoch etwas Positives. Im besten Fall ist das die Erkenntnis, dass es (noch) zu früh ist die Verantwortung für eine solche Aufgabe zu übernehmen und der Weg dorthin zwar steinig ist, aber immerhin begehbar.

[Christian Kruse]

Hallo 1unitedpower,

Man salzt doch Hashes vor allem dafür, damit in einer Passwortdatenbank gleich gewählte Passwörter eben nicht den gleichen Hash bekommen.

Das ist ein wesentlicher Punkt, weswegen man Hashes salzt. Es gibt aber noch einen weiteren: Für ungesalzene Hashes kursieren Regenbogentabellen, mit deren Hilfe man kostengünstig Kollisionen berechnen kann.

Auch hier nochmal erwähnt: gängige Verfahren (PBKDF2, Bcrypt, Argon2) nutzen key derivation und kein reines Hashing mehr; der Effekt ist zwar der gleiche (ich bekomme einen Hash, den ich in eine Datenbank schreiben kann und das Passwort liegt nicht mehr im Klartext vor), aber diese Algorithmen sind darauf ausgelegt, möglichst viel Rechenzeit/Speicher zu nutzen, um Brute-Force-Angriffe zu erschweren und Brute-Force-Angriffe auf etwa Grafikkarten zu verhindern.

Außerdem gibt es noch einen essentiellen Unterschied: man hat die Fehlerquelle Salts entfernt. Der Anwendungsentwickler muss nicht mehr daran denken, Salts zu verwenden, das machen die neueren Algorithmen intern.

In aller Deutlichkeit: Man sollte keine Hash-Funktionen wie die SHA-Familie, MD5 oder ähnliches nutzen, um Passwörter zu hashen! Diese Funktionen sind nicht dazu geeignet.

LG,
CK

[TS]

Hello,

[...]

Das würde bedeuten, dass wir z. Zt. die Funktion password_hash() von PHP mit dem $algo-Argument PASSWORD_BCRYPT nutzen sollten und können?

Die Einschränkung auf 60 Zeichen Output ist nicht (sooo) relevant?

Ist crypt soviel löchriger?

Wenn man bei der Anmeldung am System einen Session-Token erzeugt, ist es dann sinnvoll, für die Dauer der Session selber zusätzlich auch einen Fingerprint des Client zu speichern und bei jedem Request auf die Session zu vergleichen? Dann hätte man zumindest eine Chance, ein entführtes Session-Token zu erkennen, oder?

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

[...]

Das würde bedueten, dass wir z. Zt. die Funktion password_hash() von PHP mit dem $algo-Argument PASSWORD_BCRYPT nutzen sollten und können?

Ja.

Die Einschränkung auf 60 Zeichen Output ist nicht (sooo) relevant?

Bcrypt ist derzeit auf 56 Byte lange Passwörter beschränkt. Das ist für die meisten Passwörter ausreichend; modernere Algorithmen haben das allerdings schon bedacht und haben diese Einschränkung nicht mehr (etwa Argon2), die müssen allerdings noch battle-tested werden.

Das Resultat ist immer 60 Zeichen lang (das Salt muss ja noch mit gespeichert werden). Das ist zur Zeit ausreichend sicher.

Wenn dir diese Einschränkungen nicht passen, verwende PBKDF2 oder, wenn du mutig bist, Argon2.

Ist crypt soviel löchriger?

Bei crypt() ist vor allem abhängig vom OS, welcher Hashing-Algorithmus dahinter steckt. Und je nach Salt wird auch noch ein Fallback auf schwächere Hashing-Algorithmen, etwa MD5, gemacht. Nein, besser password_hash() nutzen.

Wenn man bei der Anmeldung am System einen Session-Token erzeugt, ist es dann sinnvoll, für die Dauer der Session selber zusätzlich auch einen Fingerprint des Client zu speichern und bei jedem Request auf die Session zu vergleichen? Dann hätte man zumindest eine Chance, ein entführtes Session-Token zu erkennen, oder?

Das ist zwar ein ganz anderes Thema, aber von mir aus 😉

Gegen session hijacking helfen vor allem erstmal, Session-Cookies auf secure und httponly zu setzen. Damit sind die beiden grössten Angriffsvektoren, nämlich eine XSS-Lücke oder das ablauschen der Verbindung, schonmal beseitigt. Ausserdem generiert man nach einem erfolgreichen Login eine neue Session-ID, um zu verhindern, dass dem User eine manipulierte Session-ID untergeschoben wurde.

Session fingerprinting wird manchmal zwar auch benutzt, ist aber sehr kompliziert umzusetzen und sorgt oft dafür, dass der User aus der Session fliegt, weil der Browser irgendwas ändert, weil die SSL-Session erneuert wird, oder, oder, oder. Ich würde davon immer abraten, der Algorithmus ist zu fragil.

LG,
CK

[Matthias Apsel]

Hallo 1unitedpower,

Meine Hoffnung ist, dass sich Mitleser(innen), wenn sie je in die Situation geraten, ein sicheres Authentifizierungsystem implementieren zu müssen, daran erinnern, dass es für den Ernstfall deutlich mehr zu berücksichtigen gilt.

Richtig.

Ich will für die Komplexität von sicherheitskritischen Software-Systemen sensibilisieren.

Wichtig.

Insofern ist es meinem Ziel sogar dienlich, wenn ein(e) Leser(in) aus seiner/ihrer Komfortzone gerissen wird und sich von der Materie überfordert fühlt. Das mag ein unangehmes Gefühl in ihm oder ihr auslösen, aber es hat dennoch etwas Positives. Im besten Fall ist das die Erkenntnis, dass es (noch) zu früh ist die Verantwortung für eine solche Aufgabe zu übernehmen und der Weg dorthin zwar steinig ist, aber immerhin begehbar.

Für den konkreten Fall hätte imho gereicht: „Wenn du aber je in die Situation gerätst, ein wirklich sicheres Authentifizierungsystem implementieren zu müssen, ist diese Variante vollkommen ungeeignet.“

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Insofern ist es meinem Ziel sogar dienlich, wenn ein(e) Leser(in) aus seiner/ihrer Komfortzone gerissen wird und sich von der Materie überfordert fühlt. Das mag ein unangehmes Gefühl in ihm oder ihr auslösen, aber es hat dennoch etwas Positives. Im besten Fall ist das die Erkenntnis, dass es (noch) zu früh ist die Verantwortung für eine solche Aufgabe zu übernehmen und der Weg dorthin zwar steinig ist, aber immerhin begehbar.

Für den konkreten Fall hätte imho gereicht: „Wenn du aber je in die Situation gerätst, ein wirklich sicheres Authentifizierungsystem implementieren zu müssen, ist diese Variante vollkommen ungeeignet.“

Ungefähr darauf wollte ich auch hinaus.

Man muss dem Fragesteller einen gehörigen Respekt vor der Programmierung von sicheren Authentifizierungssystemen einbläuen. Darin sind wir uns alle einig.

Aber ich muss dem Fragesteller auch ein Gefühl dafür vermitteln, wann welches Sicherheitslevel angebracht ist, und, dass er seine konkrete Problemstellung auch mit einem deutlich geringeren Aufwand umsetzen kann.

Wenn man nur Ersteres tut, dann nimmt man damit in Kauf, dass der Fragesteller meint, die komplexe, ihn überfordernde Antwort sei das, was er in seinem Problemfall machen muss, woraufhin er frustriert die Waffen streckt und aufgibt.

Wenn ein Schüler von mir wissen will, wie man zwei Zahlen addiert, dann antworte ich ihm auch nicht mit einer Einführung der Zahlenräume und Peano-Axiome. Die kann ich erwähnen, wenn er an einer tieferen Beschäftigung mit dem Thema interessiert ist.

Ich hatte in der 8. Klasse einen Mathelehrer, war ein klasse Typ. Menschlich gesehen. Aber irgendwie hat ers ständig geschafft, bei der Vermittlung seines Stoffes in Oberstufenthemen abzurutschen. Die Stunden waren angenehm für mich, er hat vorne was erzählt, was ich die nächsten Jahre sowieso nicht brauchte und abgesehen davon auch gar nicht verstanden habe. Aber für die mathematischen Herausforderungen, die dann in der Klassenarbeit auf mich zukamen, habe ich in der Zeit nichts gelernt. Was man dann an den Noten nachher auch feststellen konnte. Sinnvoller wärs gewesen, wenn er das Niveau des zu vermittelnden Lernstoffes an die konkreten Anforderungen angepasst hätte.

Grüße,

RIDER

[TS]

Hello,

Passwörter als Klartext zu hinterlegen ist keine gute Idee. Besser man speichert nur einen gesalzenen Hash.

Man salzt doch Hashes vor allem dafür, damit in einer Passwortdatenbank gleich gewählte Passwörter eben nicht den gleichen Hash bekommen.

Das würde also bedeuten, dass Du eine zusätzliche Spalte "SALT" in deiner Tabelle oder der zuständigen View abspeicherst?

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

Passwörter als Klartext zu hinterlegen ist keine gute Idee. Besser man speichert nur einen gesalzenen Hash.

Man salzt doch Hashes vor allem dafür, damit in einer Passwortdatenbank gleich gewählte Passwörter eben nicht den gleichen Hash bekommen.

Das würde also bedeuten, dass Du eine zusätzliche Spalte "SALT" in deiner Tabelle oder der zuständigen View abspeicherst?

Nein. Erstens: siehe dieses Posting. Zweitens ist der Salt idR Teil der Serialisierung des Hashes; es wird also nicht der reine Hash kodiert, sondern hexdump(concat(salt, hash)) (Pseudocode).

LG,
CK

[TS]

Hello,

Passwörter als Klartext zu hinterlegen ist keine gute Idee. Besser man speichert nur einen gesalzenen Hash.

Man salzt doch Hashes vor allem dafür, damit in einer Passwortdatenbank gleich gewählte Passwörter eben nicht den gleichen Hash bekommen.

Das würde also bedeuten, dass Du eine zusätzliche Spalte "SALT" in deiner Tabelle oder der zuständigen View abspeicherst?

Nein. Erstens: siehe dieses Posting. Zweitens ist der Salt idR Teil der Serialisierung des Hashes; es wird also nicht der reine Hash kodiert, sondern hexdump(concat(salt, hash)) (Pseudocode).

Verstehe ich nicht. Hast Du eventuell meine Frage nicht verstanden?

Ich muss doch beim Vergleich am Server wissen, mit welchem Salt der Hash erzeugt wurde? Und den darf ich auch nicht einfach erkennbar im Hash speichern, dann wäre ja nichts gewonnen.

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

Verstehe ich nicht. Hast Du eventuell meine Frage nicht verstanden?

Ich habe deine Frage sehr wohl verstanden.

Ich muss doch beim Vergleich am Server wissen, mit welchem Salt der Hash erzeugt wurde?

Der Salt wird als Teil der Hash-Serialisierung gespeichert. Siehe den Pseudocode oben.

Und den darf ich auch nicht einfach erkennbar im Hash speichern, dann wäre ja nichts gewonnen.

???

Ob ich den Hash in einer Datenbank-Spalte speichere oder als Teil der Serialisierung, das bleibt sich technisch gleich. Und der Salt ist kein Teil des Geheimnisses, er ist einfach nur eine Folge von zufälligen Bytes, die sich im Optimalfall bei jedem neu eurzeugten Hash unterscheiden.

Der Salt ist kein zusätzliches Passwort, sondern eine Absicherung gegen rainbow tables und gleiche Passwort-Hashes. Das einzige, was der Algorithmus (vereinfacht gesagt) mit dem Salt macht ist ihn an das Passwort zu hängen. Statt hash(password) wird also hash(concat(salt, password)) ausgeführt. Ob der Angreifer den Salt kennt oder nicht ist irrelevant, er hat nur den Zweck ihm das Leben schwerer zu machen und das brute force zu verlangsamen (weil jedes Passwort einzeln gebruteforced werden muss statt in einer Rainbow table nachzugucken).

LG,
CK

[pl]

Ja, natürlich geht das. Du erstellst eine Login-Seite mit dem entsprechenden Formular. Das sieht dann so aus, also anstelle Benutzername wird bei Dir dann halt nur das Passwort eingegeben. MfG