Forum: www.mikrocontroller.net Einloggen ohne Cookies


von Sebastian (Gast)


Lesenswert?

Angeregt durch einen Thread im ELKO:

http://www.elektronik-kompendium.de/forum/board_entry.php?id=244325&page=0&category=all&order=last_answer&descasc=DESC
>
1
https://www.elektronik-kompendium.de/forum/login.php?username=matzi682015&userpw=xxx
>Da wo die 3 x sind schriebst Du Dein Passwort hin und legst Dir
>die Verknüpfung auf den Desktop.
>
>Und schon bist Du jedesmal direkt eingelogt.

Könnte man hier nicht auch so etwas einrichten?

Ein sehr hilfreiches Feature, wie ich finde. Ein einloggen ohne Cookies 
würde auch dazu beitragen, dass weniger Unfug mit fremden Nick's 
getrieben wird.

Ggf. kann man ja noch einen Accounttyp einrichten, der nur eine 
Namensreservierung ist und keine weitere Funktionalitäten bietet. Bzw. 
nur einen Account für alles, der sich aber entsprechend einstellen 
lässt.

Was meint ihr dazu?

von Sebastian (Gast)


Lesenswert?

Vor allem kann man sich von all seinen Geräten einloggen, ohne das 
Passwort immer raussuchen zu müssen. Man kann einfach den Link 
abspeichern.

von Hans (Gast)


Lesenswert?

Sebastian schrieb:
> Ein sehr hilfreiches Feature, wie ich finde.

Ich nicht. Zum einen kann jeder in deiner Chronik dein Passwort im 
Klartext sehen, zum anderen müssen Benutzername und Passwort bei jedem 
Seitenaufruf erneut übergeben werden. Jeder, der also die URL sieht kann 
sich auch einloggen. Wer die URL nur kurz kopiert, um sie irgendwo zu 
teilen, teilt möglicherweise auch gleich seine Benutzerdaten mit.

Ich sehe auch kein Problem mit Cookies. Tracking Cookies kann man recht 
zuverlässig blockieren. Session Cookies sorgen dagegen für erheblich 
mehr Sicherheit, da eben nicht mehr bei jedem Seitenaufruf Benutzername 
und Passwort mitgeschickt werden müssen.

von Sebastian (Gast)


Lesenswert?

Naja, man übergibt das Passwort doch ohne (gespeicherten) Cookie sowieso 
bei Start der Sitzung (gut, nicht im Klartext). In der aktuellen Sitzung 
bliebe der Login ja bestehen. Klar kann sich dann jeder, der diese URL 
sieht einloggen. Aber ich klicke doch nur einmal beim Start der Sitzung 
drauf und dann gibt's z.B. direkt eine Weiterleitung auf die Startseite 
von µC.net. Dann brauche ich den Link mit Klartext Passwort nicht mehr.

Von daher finde ich das nicht so schlimm. Außerdem müsste es ja nicht 
jeder nutzen. Und diejenigen, die es machen möchten, wissen von der 
"Gefahr". Und was will schon jemand mit einem Benutzernamen aus diesem 
Forum? Ein Passwort nur dafür ist natürlich selbstverständlich.

Mann kann es auch einfach so machen, dass wenn man über den Link 
eingeloggt ist, einfach nur unter seinem Namen schreibt. Das 
Benutzerkonto könnte dann weiterhin ein anderes Passwort haben. Dort 
muss man sich dann richtig einloggen.

von Daniel A. (daniel-a)


Lesenswert?

Wenn man soetwas schon umsetzt, dann wenigstens richtig. Eine URL kann 
auch bei HTTP Benutzername & Passwort haben. Das Format wäre dann 
https://username:password@domain/

: Bearbeitet durch User
von Dirk D. (dicky_d)


Lesenswert?

Sebastian schrieb:
> Vor allem kann man sich von all seinen Geräten einloggen, ohne das
> Passwort immer raussuchen zu müssen. Man kann einfach den Link
> abspeichern.

ich kann mich auch so überall einloggen ohne das Passwort rauszusuchen, 
es ist im Passwortmanager gespeichert.

Wo ist da jetzt der unterschied?

von Hans (Gast)


Lesenswert?

Sebastian schrieb:
> Das
> Benutzerkonto könnte dann weiterhin ein anderes Passwort haben. Dort
> muss man sich dann richtig einloggen.

Das klingt nach sehr viel Aufwand für einen relativ kleinen Nutzerkreis.

Sebastian schrieb:
> In der aktuellen Sitzung
> bliebe der Login ja bestehen.

Wie funktioniert das denn? Woher weiß der Server, dass ich auf den Link 
geklickt habe und nun eingeloggt bin?

Daniel A. schrieb:
> https://username:password@domain/

Bei der Lösung wird das Passwort auch bei jedem Aufruf mitgeschickt. Der 
Unterschied ist nur, dass die meisten Browser die Benutzerdaten in der 
URL verbergen. Mich würde allerdings wirklich mal interessieren, wie der 
TO umsetzen will, dass das Passwort eben nicht jedes mal mitgeschickt 
werden muss.

von Dirk D. (dicky_d)


Lesenswert?

Hans schrieb:
> Mich würde allerdings wirklich mal interessieren, wie der
> TO umsetzen will, dass das Passwort eben nicht jedes mal mitgeschickt
> werden muss.

Cookies, ist doch klar :D

von Jan H. (j_hansen)


Lesenswert?

Der Schrecken jedes Softwareentwicklers: "Kannst du nicht einen 
komplexen Murks den niemand verwenden wird aus einem absurdem Grund 
einbauen, auch wenn der jetzige sauber implementierte Mechanismus dafür 
super funktioniert?" Schön, wenn man da einfach "Nö" sagen kann. Blöd, 
wenn der Kunde König ist.

von Hans (Gast)


Lesenswert?

Dirk D. schrieb:
> Cookies, ist doch klar :D

Das wollte ich den TO eigentlich selbst herausfinden lassen.

von Sebastian (Gast)


Lesenswert?

Hans schrieb:
> Das wollte ich den TO eigentlich selbst herausfinden lassen.

So blöd bin ich auch nicht... In der Sitzung hätte ich Cookies, war 
etwas unglücklich formuliert.

Es ging mir darum, das manuelle einloggen einzusparen, wenn ich meine 
Cookies nach jeder Sitzung lösche (V-Maschine)...

Und PW-Manager sind mal außen vor. Mein Handy z.B. könnte das auch 
nicht, aber einen Link speichern schon.

von Dirk D. (dicky_d)


Lesenswert?

Sebastian schrieb:

> Es ging mir darum, das manuelle einloggen einzusparen, wenn ich meine
> Cookies nach jeder Sitzung lösche (V-Maschine)...

wo kommt den dann der link her?

>
> Und PW-Manager sind mal außen vor. Mein Handy z.B. könnte das auch
> nicht, aber einen Link speichern schon.
was für ein Handy kann Lesezeichen verwalten aber weder cookies halten 
noch Passwörter speichern?

von Daniel A. (daniel-a)


Lesenswert?

JavaScript:
1
(function(){
2
  login("Benutzername hier einsetzen","Passwort hier einsetzen");
3
  function login( username, password ){
4
    var f = document.createElement("iframe");
5
    f.onload=function(){
6
      var form = f.contentDocument.querySelector("form");
7
      form.name.value = username;
8
      form.password.value = password;
9
      f.onload = function(){
10
        location.reload();
11
      };
12
      form.submit.click();
13
    };
14
    f.style.visibility = "hidden";
15
    f.src = "https://www.mikrocontroller.net/user/login";
16
    document.body.appendChild(f);
17
  }
18
})();

Bookmarklet, kannst du wie einen Link speichern:
1
javascript:void((function(){login("Benutzername hier einsetzen","Passwort hier einsetzen");function login( username, password ){var f = document.createElement("iframe");f.onload=function(){var form = f.contentDocument.querySelector("form");form.name.value = username;form.password.value = password;f.onload = function(){location.reload();};form.submit.click();};f.style.visibility = "hidden";f.src = "https://www.mikrocontroller.net/user/login";document.body.appendChild(f);}})());

von Hans (Gast)


Lesenswert?

Sebastian schrieb:
> So blöd bin ich auch nicht... In der Sitzung hätte ich Cookies, war
> etwas unglücklich formuliert.

Dann ist dein konkretes Problem also Login per HTTP GET anstatt per 
POST. Wie oben beschrieben kann man das allerdings relativ leicht mit 
einem Javascript erreichen.

von Sheeva P. (sheevaplug)


Lesenswert?

Hans schrieb:
> Ich nicht. Zum einen kann jeder in deiner Chronik dein Passwort im
> Klartext sehen,

Das ist wahr, aber natürlich nur dann ein Problem, wenn jemand an die 
Chronik oder den Desktop-Link kommen kann -- und die meisten Menschen 
hätten in so einem Fall vermutlich ganz andere Probleme als dieses.

> zum anderen müssen Benutzername und Passwort bei jedem
> Seitenaufruf erneut übergeben werden. Jeder, der also die URL sieht kann
> sich auch einloggen. Wer die URL nur kurz kopiert, um sie irgendwo zu
> teilen, teilt möglicherweise auch gleich seine Benutzerdaten mit.

Nein, nicht unbedingt. Nach dem Login kann ein Session Cookie gesetzt 
und dann auf eine Seite redirected werden, deren URL keine Credentials 
mehr enthält.

> Ich sehe auch kein Problem mit Cookies. Tracking Cookies kann man recht
> zuverlässig blockieren. Session Cookies sorgen dagegen für erheblich
> mehr Sicherheit, da eben nicht mehr bei jedem Seitenaufruf Benutzername
> und Passwort mitgeschickt werden müssen.

Wenn ich den TO richtig verstanden habe, ging es ihm nicht darum, 
Cookies komplett zu vermeiden, sondern nur darum, sich ohne Cookie mit 
einem Klick anmelden zu können. Im Übrigen hast Du bei Cookies ein 
ähnliches Problem, wie Du es oben bei der Chronik (oder, das habe ich 
hinzugefügt, dem Link auf dem Desktop) hast: wenn ein Angreifer an Deine 
Chronik kommen kann, dann hat er auch Zugang zu Deinen Cookies.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.