webForumDet fria alternativet

Password Generator

19 svar · 1 169 visningar · startad av Palle

PalleMedlem sedan apr. 20003 174 inlägg
#1

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
#2

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
#3
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
#4

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
#5

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
#6

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
#7
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
#8

Kan vara smart att göra så, ja... :)

OveRRidEMedlem sedan feb. 200112 078 inlägg
#9

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
#10

..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
#11

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
#12

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
#13

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?

m_soderlundMedlem sedan sep. 20026 425 inlägg
#14

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
#15

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å?

NickemannenMedlem sedan aug. 20003 575 inlägg
#16

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

DashiMedlem sedan jan. 2005296 inlägg
#17

OveRRidE skrev:

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...

Mvh //Dashi

JosefMedlem sedan mars 20023 561 inlägg
#18

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
#19

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
#20

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.

261 ms totalt · 3 externa anrop · v20260731065814-full.3ab8d573
138 ms — hämta forumlista (db)
122 ms — hämta statistik (db)
138 ms — hämta tråd, inlägg och bilagor (db)