Wachtwoord en gebruikersnaam kwijt.... Resetten met unieke code?
Ik sla het IP al op.
Je kunt ook door de aanvraag via email achterhalen of het IP overeenkomt met hetgene die bij de email hoort.
Dan kun je direct de aanvraag blokkeren.
En de eigenaar van de email waarschuwen dat iemand met ander ip adres een melding wilde doen...
Wel leuk om eens uit te proberen...
Hoewel IP ook te omzeilen is natuurlijk.
Maar als optie wel leuk.
Jij had bij het inloggen toch ook eens controle op IP als optie toegevoegd?
Ik heb dat nu ook als extra (aanvinken).
Moet ik nu bij aanvinken op de thuisip alle inlogpogingen elders direct blokketen ?
Want nu heb ik het nog dat wanneer elders ingelogd wordt de keuze er weer is om aan te vinken.
Gewijzigd op 30/10/2017 00:46:25 door Hans De Ridder
Ik had in een vroeger inlog-systeem (inmiddels offline) een optie ingebouwd om een inlog-sessie te locken op IP. Dit hield in dat de gemaakte inlogsessie alleen maar werkte op het IP-adres waarmee je inlogt. Hiermee werden er geen andere sessies zomaar afgesloten, en het moest session-hijacking voorkomen. Het hele inlog-systeem werkte niet op PHP-sessions, maar op cookies met een unieke hash en de userID.
Het voordeel was dat de gebruiker eenvoudig controle had op zijn openstaande inlog-sessies.
Gewijzigd op 30/10/2017 00:56:40 door - Ariën -
Bedankt voor de info...
Opsich is het veilig, maar het ligt er wel aan wat je in de cookies precies opslaat.
Ik moet weer even terug in de tijd hoe ik dit gedaan heb.
Want aan een waarde (de variabele) heb ik toch ook genoeg?
Die moeten samen dus kloppen met de opgeslagen waarde voordat er toegang is tot het openbare gedeelte met de reactie mogelijkheid.
Mocht een cookie niet meer aanwezig zijn (pc opgeschoond), dan moet men weer eerst 1 keer inloggen om weer een cookie te produceren.
- Ariën - op 28/10/2017 00:32:38:
Waarom niet meteen je mailadres als gebruikersnaam laten gebruiken,
Die vergeet iemand niet zo snel, en is zelfs uniek.
Die vergeet iemand niet zo snel, en is zelfs uniek.
Offtopic; even een gedachtenspinsel:
Domein X.nl A record --> IPv4 naar VPS 1
Zelfde domein X.nl AAAA record --> IPv6 naar VPS 2
In hoeverre is het nu nog uniek?
E-mail is geen DNS verwijzing, dus nog steeds uniek ;-)
Edit: een MX record is niet noodzakelijk, dit kan ook via de A record, dus dit zou ook via de AAAA record kunnen verlopen, wat dus inhoud dat een tweede VPS ingezet kan worden, dus 1 domein, 2 stromen, 2 VPSen, dus niet meer uniek.
Gewijzigd op 02/11/2017 12:54:09 door E vH
Uiteraard is dat zo, een dom geconfigureerde DNS doet daar niets aan af. E-mail gaat maar 1 kant op, ongeacht of je meerdere A records inzet of AAAA records toevoegt. Het eindpunt wordt wat onvoorspelbaarder, maar dat is niet de schuld van het adres op zichzelf.
Met de nadruk op "uniek".
Natuurlijk snap ik dat "[email protected]" uniek is in zekere zin, er is er namelijk maar 1 van, maar in de praktijk zouden dit er dus best "meerdere" [email protected] kunnen zijn, verdeelt over meerdere mailservers, afhankelijk van de route van de ontvanger.
Ik vind daarom ook dat "uniek", niet de lading denkt, mede omdat het op diverse manieren afgevangen kan worden, zonder de daadwerkelijke gebruiker te verifieren.
Het is een aanname; dat de route klopt + de SPF / PTR records etc allemaal ingesteld zijn om maar te verifieren dat het betreffende domein ook daadwerkelijk op die computer afgehandeld word.
Maar vanaf het punt dat een e-mail wordt verzonden vanaf een webserver --> lets say: $mail->send(); dat al die checks niet plaats vinden, dus de eindgebruiker is niet "gegarandeerd" als je het mij vraagt.
Op een zeker punt zul je er toch vanuit moeten gaan dat een beheerder zijn werk goed gedaan heeft, en niet vanuit het zuiver theoretisch oogpunt beredeneren dat e-mail op verschillende servers uit kan komen. Sterker nog, dat is een ontwerpbeslissing die ook voor MX records genomen is voor het geval de primaire server offline is.
Een probleem van e-mail in een verificatieprocedure is verder dat het geheel nooit sterker is dan de zwakste schakel in het gehele proces voor het verzenden en ontvangen van e-mail.
Die begrijp ik even niet.
Hoofdletters: Die kun je gewoon lowercase vergelijken
Punten: een punt is een punt !?
Labels: Dat is gewoon een manier om je mail te organiseren en heeft verder niets met de inhoud van een email te maken.
Maar correct me if i am wrong
Frank: je zou ook een adres als [email protected] kunnen gebruiken, en daar binnen gmail evt op filteren. Punten bestaan binnen gmail niet: [email protected] is hetzelfde als [email protected] of desnoods [email protected].
Dan als [email protected] het hoofdadres is, dan werkt [email protected] ook. Maar ook [email protected] ook, enzovoorts.
Gewijzigd op 02/11/2017 14:01:32 door - Ariën -
Oh zo.. dat wist ik niet van die punten met gmail. Gelukkig niet iets om je zorgen over te maken alhoewel een gebruiker op die fiets twee maal zou kunnen registreren op één inbox. Kan een puntje zijn voor bepaalde toepassingen.
Ben van Velzen op 02/11/2017 13:59:27:
Ward, al die varianten komen in het account van 1 gebruiker uit, en zijn als zodanig uniek. Een gebruiker kan sowieso al meerdere adressen hebben, dus dat zou ook geen argument kunnen zijn.
Klopt, maar als je inlogsysteem een e-mailadres gebruikt (in plaats van een gebruikersnaam), dan moet je er wel rekening mee houden dat [email protected], [email protected] en [email protected] allemaal hetzelfde zijn. Met andere woorden: niet jij maar een extern systeem bepaalt welke credentials "uniek" zijn.
Punten varieer ik zelf overigens om een praktische reden: Amerikanen hebben moeite met tussenvoegsels. Voor hen is het dus ward.vanderput@ in plaats van ward.van.der.put@.