Har testat ett 20-tal olika lösenordsgeneratorer i ASP men ingen av dem fungerar nått vidare bra, jag får ständigt nya dubletter. :(
Vi har ett adressregister/mailinglista där besökarna själva anmäler sig och ett konto med unikt (?) lösenord skapas.
I dagsläget är det runt 30pers/dag som registrerar sig och det är grymt enerverande att manuellt gå in och redigera lösenorden som blir fel. x(
Har testat de flesta som finns här på wF samt ex. dessa hos 4GuysFromRolla (1), Planet SourceCode (2) och ASPin (3).
men vada.... ar det sa svart att gora en???? ta ett stort nummer, och sen kan du ju gora kolla om det losenord som skapades finns i databasen, om ja, slumpa nytt annars for in. Detta sker givetvis pa sidan som tar emot all ;)
Function getRandomChars(ByVal iNoChars)
Dim sChars, strStr
Dim i
Randomize(Timer())
sChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
sChars = sChars & "abcdefghijklmnopqrstuvwxyz"
sChars = sChars & "0123456789"
For i = 1 to iNoChars
strStr = strStr & Mid(sChars, Rnd * Len(sChars) + 1, 1)
Next
getRandomChars = strStr
End Function
Nedan utskrift ger en 30-siffrig sträng som knappast kommer att upprepas. Små och stora bokstäver, samt siffror.
response.write getRandomChars(30)
RED. Visserligen är det inget kul med lösenord som är 30 tecken långa, men man kan ju göra på ett annat sätt också.
Generera lösenordet med 6 siffror eller nåt, kolla ifall det finns i databasen, ifall det inte gör det, spara det. Om det finns, kör loopen igen.
bOk = False
While Not bOK
Set rs = [i]connection[/i].Execute ("SELECT strPassword FROM tblData WHERE strPassword = '" & getRandomChars(30) & "'"
If rs.EOF Then
bOk = True
[blue]'Lagra lösenordet...[/blue]
End If
Wend
Frågan jag ställer mig är; varför måste användarnas lösenord vara unika i databasen? Det borde väl i rimlighetens namn räcka med att användarnamnet är det (om du har ett sådant, villsäga)?
men vada.... ar det sa svart att gora en???? ta ett stort nummer, och sen kan du ju gora kolla om det losenord som skapades finns i databasen, om ja, slumpa nytt annars for in. Detta sker givetvis pa sidan som tar emot all ;)
Har redan testat en funktion typ den du så detaljrikt beskrev här ovan.. ;) ..scriptet gjorde 18 loopar
innan den skapade ett lösenord som inte redan fanns.. tog lite för lång tid för min smak. ;)
OveRRidE skrev:
Frågan jag ställer mig är; varför måste användarnas lösenord vara unika i databasen? Det borde väl i rimlighetens namn räcka med att användarnamnet är det (om du har ett sådant, villsäga)?
Vi använder bara lösenordet i detta fall.. lathet?? :OO
Får la överväga att ändra om jag inte får igång det ordentligt. ;)
bOk = False
While Not bOK
strPassw = getRandomChars(30)
Set rs = connection.Execute ("SELECT strPassword FROM tblData WHERE strPassword = '" & strPassw & "'"
If rs.EOF Then
bOk = True
'Lagra lösenordet... (strPassw alltså)
End If
Wend
En liten säkerhetsåtgärd bara, så att man inte anropar funktionen två gånger, då får man inte det lösenord som jämfördes mot databasen.
Vi använder bara lösenordet i detta fall.. lathet??
Nja, opraktiskt snarare. Knäckbart med en lösenords(form)postare dessutom, om du inte kollar HTTP_REFERER (vilket du väl gör? ;)). (Brute Force)
Man skall alltid ha ett användarnamn och ett lösenord. En användares säkerhet skall inte kompromissas med bara för att vi är utvecklare och råkar vara lata. ;)
..har nu gjort om systemet en smula så mailadressen måste användas som användarnamn till lösenordet.
Just detta fallet är inte så himla blodigt eftersom det enda som besökarna själva kan göra är att radera sig från listan. ;)
Har redan testat en funktion typ den du så detaljrikt beskrev här ovan.. ..scriptet gjorde 18 loopar
innan den skapade ett lösenord som inte redan fanns.. tog lite för lång tid för min smak.
hur manga medlemmar hade du sa du? Forstar inte hur det kan bli samma???? Vad genererar du?
Nja, opraktiskt snarare. Knäckbart med en lösenords(form)postare dessutom, om du inte kollar HTTP_REFERER (vilket du väl gör? ). (Brute Force)
På vilket sätt skyddar det att kolla HTTP_REFERER? Om nån fått för sig att knäcka lösenord med en automatiskt postare så är de väl inte dummare än att se till att fejka även HTTP_REFERER? Det är ju bara en header där klienten kan skriva precis vad den vill ..
På vilket sätt skyddar det att kolla HTTP_REFERER? Om nån fått för sig att knäcka lösenord med en automatiskt postare så är de väl inte dummare än att se till att fejka även HTTP_REFERER? Det är ju bara en header där klienten kan skriva precis vad den vill
Jag tror inte jag behöver förklara för dig varför det är bra att kolla HTTP_REFERER, men för de andras skull så..
Kommer formulärpostningen från din server (http://www.dinserver/sida.asp) så vet du att den är OK, i den mån det går.
Huruvida man kan fejka headern, det lämnar jag till andra (som dig?), men det brukar sätta stopp för de mesta enligt mig. :)
Kommer formulärpostningen från din server (http://www.dinserver/sida.asp) så vet du att den är OK, i den mån det går.
Just det, och problemet är att det inte går. HTTP_REFERER är ju bara en helt godtycklig textsträng som klienten skickar. Servern har ingen möjlighet att verifiera den. Lika lite som den kan verifiera att USER_AGENT stämmer. You cannot trust any browser passed variables.
Om någon verkligen har bestämt sig för att hacka sig förbi en inloggningssida mha nån klientmjukvara för automatiska postningar så är naturligtvis det första de gör att se till att alla headers (inkl. HTTP_REFERER) och cookies stämmer överens med det en riktig webläsare skulle skicka i samma situation.
Men visst, man får kanske ett visst skydd mot enklare försök - typ folk som får för sig att ladda ner en lokal version av sidan, editera i den, och sen köra manuellt via den. Annars är det mest ett slag i luften. Vissa surfare/proxies väljer kanske tom att aldrig skicka HTTP_REFERER (for privacy reasons). Hur gör man då? Ska man neka folk tillträde enbart pga det?
OveRRidE skrev:
Vad är ditt förslag niko?
På ökad säkerhet? Tja, inget revolutionerande. Säkra (långa) användarnamn/lösenord, parsning av all postad data och kryptering, så klart, om man behöver det.
Och om du menar lösenordsgenereringen: Precis det som redan föreslagits - Man slumpar ett hyfsat långt lösenord/id och kollar sen i databasen om det, mot förmodan, redan finns. Att det skulle kunna bli några problem med dubletter innan nästa istid om man kör >10 tecken kan jag inte riktigt förstå?
Hmm, bästa sättet att göra en Lösenordsgenerator som skall slumpa en massa samtidigt.
Är väl att köra Random plus att man har något tal som kollar vilket lösenord i ordningen det är.
Eftersom datorn inte kan slumpa ut ett tal. Den går ju efter klockan när den slumpar så den kanske använder samma tid varje gång den kör random i det scriptet som du använder.
/R
Byter inte dom 30 nya varje dag sina lösenord ?
Eller måste de använda de genererade.
Jag har antagligen missuppfattat dig med det svaret jag gav innan.
Men en grej hade ju varit en lösenordsgenerator som du inkluderar databaspostid:t i.
Alltså du gör om datapostid:t med någon andragradsekvation som du sedan gör om till boikstäver eller något
Function getRandomChars(ByVal iNoChars)
Dim sChars, strStr
Dim i
Randomize(Timer())
sChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
sChars = sChars & "abcdefghijklmnopqrstuvwxyz"
sChars = sChars & "0123456789"
For i = 1 to iNoChars
strStr = strStr & Mid(sChars, Rnd * Len(sChars) + 1, 1)
Next
getRandomChars = strStr
End Function
Nedan utskrift ger en 30-siffrig sträng som knappast kommer att upprepas. Små och stora bokstäver, samt siffror.
response.write getRandomChars(30)
Tack för koden OveRRidE, satt och leta först í 30 minuter för att hitta någon bra kod men hitta inget innan jag sökte här, funkar fin fint och är väldigt enkel att ändra om det skulle finnas behov, mycket bra jobbat, tycker du ska acceptera ditt inlägg med koden som slutligt svar Palle har nog glömt att göra det :) Tack än en gång...
Synd bara att det var en tre år gammal tråd som du drog upp. "Acceptera som slutgiltigt svar"-funktionen fanns inte ens då...
hehe ja jag vet inte, jag har inte vatt medlem så länge, men sen jag har varit medlem så har det funnits så jag trodde att det fanns, men nu finns det så kan man fixa de nu efteråt :P
