PalleMedlem sedan apr. 20003 174 inlägg Hejsan,
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).
(1) http://www.4guysfromrolla.com/webtech/122999-1.shtml
(2) http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=4&txtCodeId=7375
(3) http://www.aspin.com/home/tutorial/usermanage/randompa
Ingen fungerar bra, jag får dubletter.. :(
Någon som har några fler tips, jag är desperat. :OO
crisse6Medlem sedan dec. 20002 526 inlägg 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 ;)
OveRRidEMedlem sedan feb. 200112 078 inlägg 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.
Engine^Medlem sedan dec. 20003 887 inlägg Sedan en koll...
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
OveRRidEMedlem sedan feb. 200112 078 inlägg 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)?
PalleMedlem sedan apr. 20003 174 inlägg
crisse6 skrev:
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. ;)
OveRRidEMedlem sedan feb. 200112 078 inlägg 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.
Engine^Medlem sedan dec. 20003 887 inlägg Kan vara smart att göra så, ja... :)
OveRRidEMedlem sedan feb. 200112 078 inlägg
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. ;)
PalleMedlem sedan apr. 20003 174 inlägg ..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. ;)
Danke bitte för era tips. :e
crisse6Medlem sedan dec. 20002 526 inlägg men palle,
palle skrev:
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?
nikoMedlem sedan juni 20022 599 inlägg
OveRRidE skrev:
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 ..
OveRRidEMedlem sedan feb. 200112 078 inlägg
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. :)
Vad är ditt förslag niko?
OveRRidE skrev:
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. :)
Vad är ditt förslag niko?
Override stal mina ord. Nu ska niko förklara.
Och förresten, https://www.dinserver.se/sida.asp finns på nätet! :D
nikoMedlem sedan juni 20022 599 inlägg
m_soderlund skrev:
Nu ska niko förklara.
OK.
OveRRidE skrev:
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
JosefMedlem sedan mars 20023 561 inlägg Synd bara att det var en tre år gammal tråd som du drog upp. "Acceptera som slutgiltigt svar"-funktionen fanns inte ens då...
DashiMedlem sedan jan. 2005296 inlägg
Josef skrev:
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
LaspMedlem sedan juli 200012 980 inlägg Det visar ju att det lönar sig att söka på wF.
Att sedan överriddare la upp svaret när han var ung förändrar ju inget.