Hallo an Alle.
Ich habe auf meiner Internetseite (in einer Subdomain) einen Passwortgeschützten Bereich, und ich gebe die Zugangsberechtigung mittels htpasswd und htgroup frei.
Bisher habe ich immer per E-Mail den Link den Nutzernamen und das Passwort versendet.
Gibt es einen Möglichkeit dieses direkt im Link der E-Mail einzubauen?
So wie
privat.meineseite.de/index.html_ID=Nutzernamen_PW=Passwort
danke und cu
PS: „Gehostet bei Strato als WebVisitenkarte kein PHP und kein SQL“
Hallo,
Bisher habe ich immer per E-Mail den Link den Nutzernamen und
das Passwort versendet.
Gibt es einen Möglichkeit dieses direkt im Link der E-Mail
einzubauen?
ja, Benutzername und Passwort werden im URI vor dem Servernamen angegeben - etwa
https://benutzer:stuck\_out\_tongue:[email protected]/
Da URIs dieser Bauart auch schon von Phishern mißbraucht wurden (etwa http://[email protected]/), kann es sein, dass der Browser dem Link nur nach einer Warnung folgt (oder sich gar ganz weigert).
Da du im Brett IT-Sicherheit postest: es den Benutzern auf diese Weise einfacher zu machen, kann negative Folgen auf die Sicherheit dieses und anderer Systeme haben.
–
PHvL
Hallo,
Da URIs dieser Bauart auch schon von Phishern mißbraucht
wurden (etwa http://[email protected]/), kann es sein,
Wow! Das hat gereicht, damit sich mein Antivirendings meldet. (Uebrigens das erste mal seit der Installation vor ein paar Monaten!)
Ich nehme mal nicht an, dass jemand/ich auf so einen Link in einer Email klicken wuerde wenn sich der Antvirendings meldet, oder?
An den UP: was spricht dagegen, das Passwort normal ueber ein Formular entgegen zu nehmen? Dann kannst du auch URLs in Form www.xyz.de/login.php?name=fritz&pass=franz angeben. Vielleicht koennte man das Passwort ja noch intern einmal verschluesseln (ROT13 oder sowas einfaches), dann sieht es nicht so schlimm in der URL aus =:wink:
Ciao! Bjoern
Hallo,
Da URIs dieser Bauart auch schon von Phishern mißbraucht
wurden (etwa http://[email protected]/), kann es sein,Wow! Das hat gereicht, damit sich mein Antivirendings meldet.
aber doch wohl bitte mit einer verständlichen Warnung, was ihm an dem URI problematisch vorkommt.
Dieser URI ist auch ganz bewusst besonders problematisch, da der Benutzerteil einem Domainnamen ähnelt/entspricht - das ist ja bei regulären Benutzernamen normalerweise nicht der Fall. Das besser passende Beispiel musste ich ja in pre-Tags einschließen, weshalb es kein Link war.
An den UP: was spricht dagegen, das Passwort normal ueber ein
Formular entgegen zu nehmen?
Etwa, dass eine mal eben so in PHP hingeschluderte Authentifizierung vermutlich schlechter ist, als die Standardimplementierung in Apache. Ferner weiß der Browser des Benutzers bei den Standard-URIs, dass es sich bei Benutzernamen und Passwort um sensible Daten handelt, während dies bei möglicherweise noch verschleierten Parametern nicht unbedingt der Fall ist.
Dann kannst du auch URLs in Form
www.xyz.de/login.php?name=fritz&pass=franz angeben.
Damit den Benutzern noch weniger bewusst ist, dass dieser URI sensible Daten enthält?
Man sollte nur in begründeten Fällen vom Standardverfahren abweichen. Unabhängig davon muss man Benutzername, Passwort und Login-URI (ohne diese Information) ohnehin angeben und sollte einen personalisierten Login-URI (mit integriertem Benutzernamen und Passwort) höchstens als zusätzlichen Service anbieten.
Vielleicht koennte man das Passwort ja noch intern einmal
verschluesseln (ROT13 oder sowas einfaches), dann sieht es
nicht so schlimm in der URL aus =:wink:
Ich würde ROT13 nicht als „Verschlüsselung“ bezeichnen.
Der Versuch, dem Benutzer gegenüber zu verbergen, dass hier sensible Daten ungeschützt übertragen werden, ist sicherheitstechnisch eine Katastrophe.
–
PHvL
Vielleicht koennte man das Passwort ja noch intern einmal
verschluesseln (ROT13 oder sowas einfaches), dann sieht es
nicht so schlimm in der URL aus =:wink:Ich würde ROT13 nicht als „Verschlüsselung“ bezeichnen.
Dann halt Triple-ROT13.
Gruss vom Frank.