Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #3890 > unrolled thread

Wie kann man eine "Remember Me"-Funktionalität sicher erstellen?

Back to article view | Back to de.comp.lang.php

Contents

  Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-25 01:25 +0200
    Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-25 05:22 +0000
      Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-25 07:59 +0200
        Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-04-25 19:49 +0200
    Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Markus Grob <snoopy@ilnet.ch> - 2016-04-25 08:41 +0200
      Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-25 10:01 +0200
        Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-04-25 09:00 +0000
          Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-25 12:01 +0200
            Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? k@rl.pflaesterer.de (Karl Pflästerer) - 2016-04-25 14:02 +0200
              Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-25 18:40 +0200
                Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? k@rl.pflaesterer.de (Karl Pflästerer) - 2016-04-25 19:50 +0200
                Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-04-25 19:58 +0200
    Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-04-25 13:21 +0200
      Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-25 16:10 +0200
        Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 04:41 +0200
          Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-04-26 11:24 +0200
            Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 17:42 +0200
          Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-26 12:29 +0200
    Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 03:53 +0200
      Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-26 12:25 +0200
        Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-04-26 14:07 +0200
          Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Michael Vogel <ike@spamfence.net> - 2016-04-26 14:36 +0200
      Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Stefan Mayer <meniskus@gmx.net> - 2016-04-26 13:45 +0200
        Re: Wie kann man eine "Remember Me"-Funktionalität sicher erstellen? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 17:44 +0200

Page 1 of 2  [1] 2  Next page →

#3890 — Wie kann man eine "Remember Me"-Funktionalität sicher erstellen?

Hi!

Ich programmiere an einer Webapplikation, die eine "Remember
Me"-Funktionalität hat (gemeint ist damit, dass man sich nicht immer neu
anmelden muss, falls man einen entsprechenden Haken gesetzt hat)

Dies wurde bislang über eine Manipulation des Session-Cookies gelöst,
dies scheint aber unzuverlässig zu sein.

Ich wollte dies nun darüber lösen, dass ich über "setcookie" ein
entsprechendes Cookie mit längerer Laufzeit setze und später wieder lese.

Nun das Problem: Der Cookie-Wert wird auf dem lokalen Rechner
gespeichert. Wenn ich also z.B. den Usernamen in das Cookie schreiben
würde, könnte ein böswilliger Angreifer den Cookie manipulieren und
somit Zugriff unter jedem beliebigen Usernamen erhalten.

Es gibt "schlüsselfertige" Lösungen wie diese hier:
http://www.bitrepository.com/php-autologin.html

Aber hier wird einfach das Password per MD5 gehasht und in das Cookie
geschrieben. Zum einen sollte man MD5 nicht in sicherheitsrelevanten
Bereichen verwenden, zum anderen erscheint es mir von meinem Bauchgefühl
her nicht sicher, das Passwort in einem Cookie zu speichern.

Andere Lösungen, die ich gefunden habe, speichern beim Anmelden in der
Userdatenbank einen zufälligen Hashwert, der dann in das Cookie
geschrieben wird und der sich laufend ändert. Aber das erscheint mir
nicht sinnvoll nutzbar, wenn man von mehreren Rechnern aus arbeitet. Und
wenn es immer der gleiche Hashwert wäre, könnte der abgegriffen werden,
um sich dann mit einem anderen Rechner einzuloggen.

Gibt es "schlüsselfertige" Lösungen für PHP, die sicher sind und die es
ermöglichen, dass man die Funktionalität auf mehreren Rechnern nutzt?

Michael

[toc] | [next] | [standalone]

#3891

On Mon, 25 Apr 2016 01:25:22 Michael Vogel wrote:
> Andere Lösungen, die ich gefunden habe, speichern beim Anmelden in
> der Userdatenbank einen zufälligen Hashwert, der dann in das
> Cookie geschrieben wird und der sich laufend ändert. Aber das
> erscheint mir nicht sinnvoll nutzbar, wenn man von mehreren
> Rechnern aus arbeitet. Und wenn es immer der gleiche Hashwert
> wäre, könnte der abgegriffen werden, um sich dann mit einem
> anderen Rechner einzuloggen.

*Wenn* Du von mehreren Rechnern aus ohne explizite Anmeldung
zugreifen können möchtest, dann kannst Du entweder

a) ein gemeinsames Geheimnis auf allen Rechnern speichern und mit
dem Risiko leben, dass dieses Geheimnis trivial kopierbar ist, oder

b) für jeden Rechner ein eigenes Geheimnis erzeugen, was dann in der
Datenbank eine 1:n-Relation erfordert (also im wesentlichen eine
eigene Tabelle hierfür)

> Gibt es "schlüsselfertige" Lösungen für PHP, [...]

Ich halte das Problem in der Umsetzung für hinreichend trivial, um
nicht auf schlüsselfertige Lösungen zurückgreifen zu müssen; dafür
hast Du dann die Umsetzung zu 100% in der Hand, was auch kein
Nachteil ist.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Liebe, die nimmermehr raucht.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3892

Am 25.04.2016 um 07:22 schrieb Stefan Froehlich:

> *Wenn* Du von mehreren Rechnern aus ohne explizite Anmeldung
> zugreifen können möchtest, dann kannst Du entweder
> 
> a) ein gemeinsames Geheimnis auf allen Rechnern speichern und mit
> dem Risiko leben, dass dieses Geheimnis trivial kopierbar ist, oder
> 
> b) für jeden Rechner ein eigenes Geheimnis erzeugen, was dann in der
> Datenbank eine 1:n-Relation erfordert (also im wesentlichen eine
> eigene Tabelle hierfür)

Ich suche nach Lösung "c" :-)

Was mich dabei verwirrt, ist wie andere Systeme das gelöst haben. Ich
hab mal meine Cookies überflogen und gesehen, dass es da Systeme gab,
die einfach die Benutzerkennung im Klartext drin hatten.

>> Gibt es "schlüsselfertige" Lösungen für PHP, [...]
> 
> Ich halte das Problem in der Umsetzung für hinreichend trivial, um
> nicht auf schlüsselfertige Lösungen zurückgreifen zu müssen; dafür
> hast Du dann die Umsetzung zu 100% in der Hand, was auch kein
> Nachteil ist.

In der Regel mache ich auch lieber alles komplett selber. Aber wenn es
um sicherheitsrelevante Dinge geht, genügen manchmal kleine
Designfehler, um Scheunentore zu öffnen. Da schaue ich mir dann gerne
fertige (und sichere) Lösungen an, um sie zu analysieren.

Michael

[toc] | [prev] | [next] | [standalone]

#3901

On 2016-04-25 05:59, Michael Vogel <ike@spamfence.net> wrote:
> Was mich dabei verwirrt, ist wie andere Systeme das gelöst haben. Ich
> hab mal meine Cookies überflogen und gesehen, dass es da Systeme gab,
> die einfach die Benutzerkennung im Klartext drin hatten.
[...]
> In der Regel mache ich auch lieber alles komplett selber. Aber wenn es
> um sicherheitsrelevante Dinge geht, genügen manchmal kleine
> Designfehler, um Scheunentore zu öffnen. Da schaue ich mir dann gerne
> fertige (und sichere) Lösungen an, um sie zu analysieren.

Das ist prinzipiell eine gute Einstellung. Das Problem ist, dass
"fertige Lösungen", die man im Internet findet, sehr oft nicht sicher
sind. Wie Du ja bereits bemerkt hast, gibt es da recht abenteuerliche
Ansätze, denen man anmerkt, dass sich der Programmierer nicht wirklich
viel Gedanken gemacht hat. Gefährlicher sind aber die, wo sich der
Programmierer sehr wohl Gedanken gemacht hat, aber halt einen Fehler
gemacht hat. Im Prinzip brauchst Du mindestens das gleiche Wissen, um
die Sicherheit der Lösung eines anderen beurteilen zu können, wie um
eine eigene zu schreiben.

Bei den grundlegenden Bausteinen (AES, SHAn, ...) kannst Du davon
ausgehen, dass ich diverse ernstzunehmende Kryptographen damit
beschäftigt haben und man™ weiß, wie sicher oder unsicher die sind. Aber
bei einem Stück PHP-Code, selbst wenn es aus einer einigermaßen
bekannten Applikation stammt?

        hp

-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#3893

Michael Vogel schrieb:
> Ich programmiere an einer Webapplikation, die eine "Remember
> Me"-Funktionalität hat

> Es gibt "schlüsselfertige" Lösungen wie diese hier:
> http://www.bitrepository.com/php-autologin.html
>
> Aber hier wird einfach das Password per MD5 gehasht und in das Cookie
> geschrieben.

Dann verwende halt einen anderen Verschlüsslungs-Algorithmus und salze 
die Passwörter. Brute Force ist damit zwar möglich, doch normalerweise 
uninteressant.

Der Benutzer muss sich dann zwar pro genutztem Rechner einmal anmelden, 
doch dafür ist die Anmeldung relativ sicher. Aus Sicherheitsgründen 
sollte das Passwort trotzdem nach einer gewissen Zeit geändert werden. 
Aus diesem Grund bevorzuge ich halt ein normales Cookie. Die meisten 
User haben Passwort Manager und dann sind die für die Sicherheit selber 
zuständig.

Gruss, Markus

[toc] | [prev] | [next] | [standalone]

#3894

Am 25.04.2016 um 08:41 schrieb Markus Grob:

> Dann verwende halt einen anderen Verschlüsslungs-Algorithmus und salze
> die Passwörter. Brute Force ist damit zwar möglich, doch normalerweise
> uninteressant.

Ich war zwischendrin am Überlegen, im Salt zusätzlich ein paar
Client-Informationen (wie "HTTP_ACCEPT_ENCODING",
"HTTP_ACCEPT_LANGUAGE", "HTTP_ACCEPT" und "HTTP_USER_AGENT") zu
verwenden (zusätzlich zu einem zufällig erzeugtem Wert).

Ich frage mich nur, ob das dann eher aus der Kategorie "Security by
Obscurity" stammt oder sinnvoll ist - oder sogar hinderlich. Das Problem
wäre ja, dass jedes Browser-Update bewirken würde, dass die Leute sich
neu anmelden müssten.

> Aus diesem Grund bevorzuge ich halt ein normales Cookie. Die meisten
> User haben Passwort Manager und dann sind die für die Sicherheit selber
> zuständig.

Sag das mal unseren Usern ...

Michael

[toc] | [prev] | [next] | [standalone]

#3895

On Mon, 25 Apr 2016 10:01:28 Michael Vogel wrote:
> Am 25.04.2016 um 08:41 schrieb Markus Grob:
> > Dann verwende halt einen anderen Verschlüsslungs-Algorithmus und
> > salze die Passwörter. Brute Force ist damit zwar möglich, doch
> > normalerweise uninteressant.
 
> Ich war zwischendrin am Überlegen, im Salt zusätzlich ein paar
> Client-Informationen (wie "HTTP_ACCEPT_ENCODING",
> "HTTP_ACCEPT_LANGUAGE", "HTTP_ACCEPT" und "HTTP_USER_AGENT") zu
> verwenden (zusätzlich zu einem zufällig erzeugtem Wert).
 
> Ich frage mich nur, ob das dann eher aus der Kategorie "Security
> by Obscurity" stammt oder sinnvoll ist - oder sogar hinderlich.
> Das Problem wäre ja, dass jedes Browser-Update bewirken würde,
> dass die Leute sich neu anmelden müssten.

Das Ausmaß an Hinderlichkeit hielte ich für überschaubar: eine neue
Anmeldung nach einem Update ist sicherlich jedem zumutbar.

Der Nutzen jedoch ist ähnlich überschaubar: Du gewinnst damit
nichts, was Du nicht auch schon mit dem Cookie alleine hättest.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

2016! Das Jahr von Stefan. Sanfter wird's nie.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#3896

Am 25.04.2016 um 11:00 schrieb Stefan Froehlich:
> On Mon, 25 Apr 2016 10:01:28 Michael Vogel wrote:
>> Ich war zwischendrin am Überlegen, im Salt zusätzlich ein paar
>> Client-Informationen (wie "HTTP_ACCEPT_ENCODING",
>> "HTTP_ACCEPT_LANGUAGE", "HTTP_ACCEPT" und "HTTP_USER_AGENT") zu
>> verwenden (zusätzlich zu einem zufällig erzeugtem Wert).
>  
> Das Ausmaß an Hinderlichkeit hielte ich für überschaubar: eine neue
> Anmeldung nach einem Update ist sicherlich jedem zumutbar.
> 
> Der Nutzen jedoch ist ähnlich überschaubar: Du gewinnst damit
> nichts, was Du nicht auch schon mit dem Cookie alleine hättest.

Ich baue den Hash jetzt aus dem gehashten Passwort, dem privaten
User-Key und dem privaten Server-Key zusammen. Dadurch ist
sichergestellt, dass zwei User mit gleichen Passwörtern dennoch
unterschiedliche Hash-Werte haben, dass eine Passwort-Änderung eine
Hash-Änderung bewirkt und dass ein Umzug eines Users auf einen anderen
Server (unter Beibehaltung des Passworts und privaten User-Keys) auch
einen geänderten Hash bewirkt. Das sollte grundsätzlich hinreichend
sicher sein.

Irgendwie hätte ich nur noch gerne eine Client-abhängige Komponente -
aber da die sich faken lässt, bringt es wahrscheinlich wenig, die noch
hinzuzufügen. Aber trotzdem hätte ich es irgendwie gerne ...

Aber ich gehe davon aus, dass meine oben beschriebene Lösung schon
halbwegs i.O. sein sollte, oder? Ich nehme jetzt "sha256" für den Hash:

https://github.com/annando/friendica/blob/1604-cookie/include/auth.php#L205-L207

Kleiner Hinweis: Der Code in dieser Datei ist aus frühen Tagen des
Projekts und hat dementsprechend viel Potential für Verbesserungen :-)

Michael

[toc] | [prev] | [next] | [standalone]

#3898

Michael Vogel <ike@spamfence.net> writes:

> Am 25.04.2016 um 11:00 schrieb Stefan Froehlich:

[...]

> Ich baue den Hash jetzt aus dem gehashten Passwort, dem privaten
> User-Key und dem privaten Server-Key zusammen. Dadurch ist
> sichergestellt, dass zwei User mit gleichen Passwörtern dennoch
> unterschiedliche Hash-Werte haben, dass eine Passwort-Änderung eine
> Hash-Änderung bewirkt und dass ein Umzug eines Users auf einen anderen
> Server (unter Beibehaltung des Passworts und privaten User-Keys) auch
> einen geänderten Hash bewirkt. Das sollte grundsätzlich hinreichend
> sicher sein.
>
> Irgendwie hätte ich nur noch gerne eine Client-abhängige Komponente -
> aber da die sich faken lässt, bringt es wahrscheinlich wenig, die noch
> hinzuzufügen. Aber trotzdem hätte ich es irgendwie gerne ...
>
> Aber ich gehe davon aus, dass meine oben beschriebene Lösung schon
> halbwegs i.O. sein sollte, oder? Ich nehme jetzt "sha256" für den Hash:
>
> https://github.com/annando/friendica/blob/1604-cookie/include/auth.php#L205-L207

Nimm doch eine Funktion, die für diesen Fall geschrieben wurde: http://www.php.net/hash_hmac



> Michael

[toc] | [prev] | [next] | [standalone]

#3900

Am 25.04.2016 um 14:02 schrieb Karl Pflästerer:

> Nimm doch eine Funktion, die für diesen Fall geschrieben wurde: http://www.php.net/hash_hmac

Ganz blöde gefragt: Welchen Vorteil habe ich von dieser Funktion? Mir
geht es ja nur darum, einen Hash-Wert zu erhalten - wie auch immer er
entstanden ist.

Michael

[toc] | [prev] | [next] | [standalone]

#3902

Michael Vogel <ike@spamfence.net> writes:

> Am 25.04.2016 um 14:02 schrieb Karl Pflästerer:
>
>> Nimm doch eine Funktion, die für diesen Fall geschrieben wurde: http://www.php.net/hash_hmac
>
> Ganz blöde gefragt: Welchen Vorteil habe ich von dieser Funktion? Mir
> geht es ja nur darum, einen Hash-Wert zu erhalten - wie auch immer er
> entstanden ist.

(https://de.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code )

Du kannst dir sicher sein, dass dieser Hash-Wert so ermittelt wurde,
dass du nicht die Sicherheit deines Systems schwächst

Dies ist dein Code:

	return(hash("sha256", get_config("system", "site_prvkey").
				$user["uprvkey"].
				$user["password"]));


get_config("system", "site_prvkey") und $user["uprvkey"] dienen als
Salt. get_config("system", "site_prvkey") ist hierbei ja wohl für alle
Nutzer dieses Systems gleich. Wenn ich es richtig lese, ist uprvkey ein
privater Schlüssel (4096 Bit lang). Nutzt es wirklich etwas den System
Schlüssel auch noch als Salt zu nehmen? Besser könnte es sein,
statdessen mehrere Iterationen bei der Bildung des Hashes vorzunehmen.

Alternativ (wird wahrscheinlich nicht gehen, weil es nur in PHP >= 5.5.0
geht) könntest dun auch password_hash nehmen. password_hash iteriert für
dich und erzeugt ein neues Salt. Dabei kannst du dich darauf verlassen,
dass diese Funktion von Programmierern entworfen wurde, die sich
ausgiebig mit Cryptographie beschäftigt haben.

Es gibt von Solar Designer phpass (http://www.openwall.com/phpass/ ).
Schau dir mal an, wie dort Passwort-hashes gebildet werden.

KP

[toc] | [prev] | [next] | [standalone]

#3903

On 2016-04-25 16:40, Michael Vogel <ike@spamfence.net> wrote:
> Am 25.04.2016 um 14:02 schrieb Karl Pflästerer:
>> Nimm doch eine Funktion, die für diesen Fall geschrieben wurde: http://www.php.net/hash_hmac
>
> Ganz blöde gefragt: Welchen Vorteil habe ich von dieser Funktion?

Sie umgeht etliche Stolpersteine an die man als Nicht-Kryptograph nicht
denkt. 

Z.B. ist es bei etlichen Hash-Methoden möglich, aus einem bekannten Hash
H(X) und einem String Y den Hash H(X || Y) zu berechnen, selbst wenn X
nicht bekannt ist. Die Konstruktion von HMAC verhindert, dass man diese
Schwäche der zugrundeliegenden Hash-Funktion ausnützen kann, selbst wenn
sie vorhanden ist.


> Mir geht es ja nur darum, einen Hash-Wert zu erhalten - wie auch immer
> er entstanden ist.

Es geht Dir auch darum, zu verhindern, dass ein Angreifer einen gültigen
Hash für von ihm bestimmte Inhalte errechnen kann.

Ganz umgehst Du dieses Problem übrigens, indem Du die relevante
Information gar nicht an den Browser schickst, sondern nur am Server
speicherst. Der Browser bekommt einen (zufälligen) Key.

        hp

-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#3897

Michael Vogel schrieb:

> Ich programmiere an einer Webapplikation, die eine "Remember
> Me"-Funktionalität hat (gemeint ist damit, dass man sich nicht immer neu
> anmelden muss, falls man einen entsprechenden Haken gesetzt hat)
> 
> Gibt es "schlüsselfertige" Lösungen für PHP, die sicher sind und die es
> ermöglichen, dass man die Funktionalität auf mehreren Rechnern nutzt?

Ich bezweifle, dass es fertige "Remember-Me" Lösungen gibt, die *sicher*
sind, siehe
<https://www.owasp.org/index.php/Guide_to_Authentication#Remember_Me>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3899

Am 25.04.2016 um 13:21 schrieb Christoph M. Becker:
> Michael Vogel schrieb:
> 
>> Gibt es "schlüsselfertige" Lösungen für PHP, die sicher sind und die es
>> ermöglichen, dass man die Funktionalität auf mehreren Rechnern nutzt?
> 
> Ich bezweifle, dass es fertige "Remember-Me" Lösungen gibt, die *sicher*
> sind, siehe
> <https://www.owasp.org/index.php/Guide_to_Authentication#Remember_Me>.

Hmm ... Das Problem ist, dass die User es so möchten. Und die Frage ist,
ob es wirklich merklich unsicherer ist, als wenn man die Passwörter in
seinem Browser speichert.

Aber ich verstehe schon, ich sollte mich nicht der Illusion hingeben, es
wirklich sicher implementieren zu können.

Ich habe es derzeit so gebaut, dass ein Cookie mit einer Laufzeit von
einer Woche gesetzt wird, das aber laufend ein neues Ablaufdatum erhält.
Damit ist zumindest die Gefahr reduziert, dass ein Dritter nach mehreren
Wochen wieder auf die Seite geht und die Sitzung übernehmen kann. (Wenn
der User sich beispielsweise beim Rechner eines Freundes angemeldet hatte)

Michael

[toc] | [prev] | [next] | [standalone]

#3905

Michael Vogel wrote:

> Christoph M. Becker wrote:
>> <https://www.owasp.org/index.php/Guide_to_Authentication#Remember_Me>.

<div style="background-color: $warning; font-size: $big; line-height: 
$readable; … border: $fat; …">
| This page contains draft content that has never been finished. Please help 
| OWASP update this content! See FixME. 
| Comment: Most content from 2008/2009 with one positive exception in 2014. 
| Please consider the Authentication Cheat Sheet instead.
</div>

→ <https://www.owasp.org/index.php/Authentication_Cheat_Sheet>

[Bitte keine “index.php”-URIs: <https://www.w3.org/QA/Tips/uri-choose>]

> Hmm ... Das Problem ist, dass die User es so möchten.

Die User sollen lernen, ihren Browser zu bedienen.  Der hat nämlich die 
Funktionalität, Benutzername und Passwort im Profil sicher sitebezogen zu 
speichern, auf Wunsch über mehrere Geräte zu synchronisieren, und 
entsprechende Login-Formulare auf Wunsch automagisch auszufüllen, in der 
Regel eingebaut.

Alternativ sollen sie lernen, relativ sichere Authentifizierungsverfahren zu 
verwenden.  Heutzutage ist es üblich, sich mit seinem 
Facebook/GitHub/Google/StackExchange/Twitter/whatever-Account zu 
authentifizieren, mit dem man ohnehin immer angemeldet ist (zum Beispiel mit 
dem Google-Account in Chrome/Chromium, und Persona in Firefox [nur noch bis 
Ende November]) – aber bitte, besonders bei Facebook, dann nur die Daten vom 
Profil abfragen, die auch wirklich zur Authentifizierung benötigt werden.  
Einzelne Staaten bieten auch anbieterunabhängige Authentifizierungslösungen 
an, zum Beispiel suisseID in der Schweiz (De-Ident von De-Mail in 
Deutschland kann demgegenüber nicht empfohlen werden, da De-Mail nach 
Aussagen von Fachleuten „absichtlich unsicher gebaut“ ist.)

Entweder alternativ oder als zweiten Authentifizierungsschritt für 
zusätzliche Sicherheit (zum Beispiel bei Google, Facebook und Twitter) gibt 
es das Login mit per E-Mail/SMS zugesendeten Einmalpasswort (“one-time 
password”), welches ausgesetzt werden kann, nachdem der Benutzer für einen 
Browser auf einem bestimmten Gerät diesen als sicher erklärt (bei Google 
möglich, Speicherung der Information in Cookie und Local Storage).  Soweit 
es E-Mail betrifft, sind Einmalpasswörter sowohl für Nutzer als auch 
Anbieter die kostengünstigste Alternative (wenn man die teilweise Aufgabe 
der Privatsphäre bei Authentifizierung bei einem Fremdanbieter als Kosten 
einkalkuliert).

<https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers> 
pp.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3906

Thomas 'PointedEars' Lahn schrieb:

> Michael Vogel wrote:
> 
>> Christoph M. Becker wrote:
>>> <https://www.owasp.org/index.php/Guide_to_Authentication#Remember_Me>.
> 
> | This page contains draft content that has never been finished. […]

Das hatte ich gesehen, habe es aber nicht weitergegeben, weil sich das
einerseits der jeweilige Besucher selbst anschauen sollte, und weil ich
den Abschnitt über "Remember Me" schon ganz richtig finde.

> [Bitte keine “index.php”-URIs: <https://www.w3.org/QA/Tips/uri-choose>]

Okay. Allerdings sollte da eigentlich der Webmaster vorsorgen – ich
hatte die URI so bei Google gefunden.

>> Hmm ... Das Problem ist, dass die User es so möchten.
> 
> Die User sollen lernen, ihren Browser zu bedienen. […]

Full ACK.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#3912

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> [Bitte keine “index.php”-URIs: <https://www.w3.org/QA/Tips/uri-choose>]
> 
> Okay. Allerdings sollte da eigentlich der Webmaster vorsorgen – ich
> hatte die URI so bei Google gefunden.

Ja, ich meinte damit, an die mitlesenden PHP-Entwickler gerichtet:
Bitte diese neue Unsitte von Wikis bei eigenen Sites nicht nachmachen.
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3908

Am 26.04.2016 um 04:41 schrieb Thomas 'PointedEars' Lahn:

> Alternativ sollen sie lernen, relativ sichere Authentifizierungsverfahren zu 
> verwenden.  Heutzutage ist es üblich, sich mit seinem 
> Facebook/GitHub/Google/StackExchange/Twitter/whatever-Account zu 
> authentifizieren, mit dem man ohnehin immer angemeldet ist

Da es sich bei der Software selber um ein soziales Netzwerk handelt und
es vor allem Leute benutzen, die etwas gegen diese zentralen Dienste
haben, ist dies keine Option. Wir haben allerdings auch die Möglichkeit,
sich per OpenID anzumelden.

Michael

[toc] | [prev] | [next] | [standalone]

#3904

Michael Vogel wrote:

> Ich programmiere an einer Webapplikation, die eine "Remember
> Me"-Funktionalität hat (gemeint ist damit, dass man sich nicht immer neu
> anmelden muss, falls man einen entsprechenden Haken gesetzt hat)
> 
> Dies wurde bislang über eine Manipulation des Session-Cookies gelöst,
> dies scheint aber unzuverlässig zu sein.

Wie kommst Du darauf?
 
> Ich wollte dies nun darüber lösen, dass ich über "setcookie" ein
> entsprechendes Cookie mit längerer Laufzeit setze und später wieder lese.

<http://php.net/manual/en/function.session-set-cookie-params.php>
 
> Nun das Problem: Der Cookie-Wert wird auf dem lokalen Rechner
> gespeichert. Wenn ich also z.B. den Usernamen in das Cookie schreiben
> würde, könnte ein böswilliger Angreifer den Cookie manipulieren und
> somit Zugriff unter jedem beliebigen Usernamen erhalten.

Mit “httponly”, was die Standardeinstellung sein sollte 
(session.cookie_httponly=1), wird das schon mal schwieriger.
 
> Es gibt "schlüsselfertige" Lösungen wie diese hier:
> http://www.bitrepository.com/php-autologin.html
> 
> Aber hier wird einfach das Password per MD5 gehasht und in das Cookie
> geschrieben. Zum einen sollte man MD5 nicht in sicherheitsrelevanten
> Bereichen verwenden,

Alle absoluten Aussagen sind falsch.

> zum anderen erscheint es mir von meinem Bauchgefühl
> her nicht sicher, das Passwort in einem Cookie zu speichern.

Darin steht _nicht_ das Passwort, sondern seine *Prüfsumme* (Hash).  MD5 
(Message-Digest Algorithm 5) ist eine kryptologische/kryptographische 
Hashfunktion, *kein* Verschlüsselungsalgorithmus.

Aber es gibt bessere Hashfunktionen als MD5 und es ist richtig, dass das 
Passwort auf den Server gehört – und *nur* der Hash davon.
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#3907

Am 26.04.2016 um 03:53 schrieb Thomas 'PointedEars' Lahn:
> Michael Vogel wrote:
> 
>> Ich programmiere an einer Webapplikation, die eine "Remember
>> Me"-Funktionalität hat (gemeint ist damit, dass man sich nicht immer neu
>> anmelden muss, falls man einen entsprechenden Haken gesetzt hat)
>>
>> Dies wurde bislang über eine Manipulation des Session-Cookies gelöst,
>> dies scheint aber unzuverlässig zu sein.
> 
> Wie kommst Du darauf?

Es gibt entsprechende Berichte von Usern und ich kann es auch
reproduzieren, dass nach mehreren Stunden der Abwesenheit die Session
anscheinend verfällt, auch wenn das Cookie noch gültig ist.

>> Nun das Problem: Der Cookie-Wert wird auf dem lokalen Rechner
>> gespeichert. Wenn ich also z.B. den Usernamen in das Cookie schreiben
>> würde, könnte ein böswilliger Angreifer den Cookie manipulieren und
>> somit Zugriff unter jedem beliebigen Usernamen erhalten.
> 
> Mit “httponly”, was die Standardeinstellung sein sollte 
> (session.cookie_httponly=1), wird das schon mal schwieriger.

Klar. Das ist gesetzt. Genauso wie ich "secure" setze, wenn der Server
entsprechend eingerichtet ist.

>> zum anderen erscheint es mir von meinem Bauchgefühl
>> her nicht sicher, das Passwort in einem Cookie zu speichern.
> 
> Darin steht _nicht_ das Passwort, sondern seine *Prüfsumme* (Hash).  MD5 
> (Message-Digest Algorithm 5) ist eine kryptologische/kryptographische 
> Hashfunktion, *kein* Verschlüsselungsalgorithmus.

Der Unterschied zwischen Hash und Verschlüsselung ist mir bewusst, ich
habe es nur verkürzt dargestellt.

> Aber es gibt bessere Hashfunktionen als MD5 und es ist richtig, dass das 
> Passwort auf den Server gehört – und *nur* der Hash davon.

Jepp.

Michael

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.lang.php

csiph-web