autogenerer password

for for = form for    :-)

prøv at søge...

http://razor.dk/php.functions.php

<?php
function password ($len=8) {
  $chars = "abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ123456789";
  mt_srand( (double) microtime() * 1000000);
  for ($i=1;$i<=$len;$i++) $out .= $chars[mt_rand(0,(strlen($chars)-1))];
  return $out;
}

//Genererer et tilfældigt password. Hvis ikke længde er sat sættes den som standard til 8.

?>

...ved godt det var et lidt tyndt svar, men det spm er altid oppe!

function lav_password( $lengde ) {
    $udvalg = "abcdefghijklmnopqrstuvwxyz0123456789";
    $antal = strlen( $udvalg )
        // brogstaver der kan bruges i dit password
    $res = "";
    for ( $i=0; $i<$lengde; $i++ ) {
        $res .= substr( $udvalg, rand(0,$antal), 1 );
    }
    return $res
}

echp lav_password( 8 );

mvh JakobA

http://www.reginscorner.dk/index.php/Scripts?Tilf%E6ldigt+kodeord

Ups. ahv har ret. min værdi $antal er en for stor.

For at du så kan have det i en variabel ->

<?php
function password ($len=8) {
  $chars = "abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ123456789";
  mt_srand( (double) microtime() * 1000000);
  for ($i=1;$i<=$len;$i++) $out .= $chars[mt_rand(0,(strlen($chars)-1))];
  return $out;
}

$password = password(8);
?>

http://www.firewerx.dk/www/passcreator.php
http://www.firewerx.dk/www/nytpassword.php
http://firewerx.dk/v2/vis_script.php?id=1

Let at kombinere

Er det muligt at få den til at vise det password den generer ??

<?php
function password ($len=8) {
  $chars = "abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ123456789";
  mt_srand( (double) microtime() * 1000000);
  for ($i=1;$i<=$len;$i++) $out .= $chars[mt_rand(0,(strlen($chars)-1))];
  return $out;
}

$password = password(8);
echo $password;
?>

<ole>

Det kan være en god idé at skrive alle tallene tre gange ... så er der næsten lige fordeling mellem små bogstaver, store bogstaver og tal  ;o)

$chars = "1234567890abcdefghijkmnopqrstuvwxyz1234567890ABCDEFGHJKLMNPQRSTUVWXYZ1234567890";


/mvh
</bole>

100 Tak for hjælpen, det spiller bare.

Så skal jeg bare ha generert og udprintet 15.000 bruger :-)

god arbejdslyst *G*

Det er vel bare at have en for-løkke der kører igennem 15.000 gange?

echo "<META HTTP-EQUIV=\"Refresh\" CONTENT=\"20; Url=ny.php\">"; :-)

asdl >>
Hvad skal det bruges til?

reloader siden og laver et nyt brugernavn & password

Det kan da ikke betale sig...

<?php
$i = 0;

while ($i < 15000) {
  // Kode der genererer brugernavn

  // kode der genererer password, fx
  //substr(md5(uniqid(rand())), 0, 8);

  // kode der indsætter det i databasen

  // Tilføj 1 til $i
  $i++;
}
?>

<META HTTP-EQUIV=\"Refresh\" CONTENT=\"20; Url=ny.php\"> vil tage:

300.000 sekunder eller
5.000 minutter eller
83,33 timer eller
3,47 døgn

Nu skal det jo være et unikt password, så mon ikke denne er bedre:

<?php
$passwords = array();
function getPass() {
    $p = substr(md5(uniqid(rand())), 0, 8);
    return $p;
}

$i = 0;
while ($i < 15000) {
    $tmpPass = getPass();
    while ( in_array($tmpPass,$passwords) ) {
        $tmpPass = getPass();
    }
    $passwords[] = $tmpPass;
   
    // kode der indsætter $tmpPass i databasen
   
    // Tilføj 1 til $i
    $i++;
}
?>

/mvh

olebole >> are you out of your fre...ng mind?  in_array er lineær, så det bliver en O(N*N) og det er skidt når N bliver så stor. Hash tabel eller en binær søgning tak.

Men hvorfor skal password egentligt være unikt? Brugernavnene er jo allerede unikke.

mvh JakobA

Hvorfor ...? Sikkerhed  :)
Hvis brugernavnet er et, brugeren selv vælger, kan du være temmelig sikker på, hun bruger det på 10 andre sites - og til at logge ind på hendes lokale computer. Altså umådelig nemt at gætte.
Det samme vil ske, hvis man lader brugeren selv vælge et password. Derfor _tildeler_ men brugerne deres passwords - og sørger for, de er unikke og svære at gætte  ;o)

Men du har da helt ret i, at in_array bliver _alt_ for tungt til 15.000 pladser. Man kan gøre sådan i stedet:

<?php
// Kan sættes ind, hvis scriptet 'timer out':
// set_time_limit(500);

$passwords = "|";
function getPass() {
    $p = substr(md5(uniqid(rand())), 0, 8);
    return $p;
}

$i = 0;
while ($i < 15000) {
    $tmpPass = getPass();
    while ( strpos($passwords, $tmpPass)!==false ) {
        $tmpPass = getPass();
    }
   
    // kode der indsætter $tmpPass i databasen
   
    $passwords .= $tmpPass."|";
   
    // Tilføj 1 til $i
    $i++;
}
?>

/mvh

stadig lineær, blot optimeret søgning når du bruger strpos.

$passwords = array();
$i = 0;
while ($i < 15000) {
    $tmpPass = getPass();
    while ( isset( $passwords[$tmpPass] ) ) {
            // det associative array bruger hashing
        $tmpPass = getPass();
    }

    // kode der indsætter $tmpPass i databasen
    $passwords[$tmpPass] = 1;

    // Tilføj 1 til $i
    $i++;
}

men prøv med et testprogram.

mvh JakobA

olebole>>> Aaargh :)

Nummer to løsning er faktisk endnu værre - sådan cirka med en faktor 8.

Hvad er der galt med hashes?

Iøvrigt er sandsynligheden for at få to ens passwords lig med 15000/58^8 ~ 10^-10 = 0.0000000001 eller 0.00000001%

Sikke en masse besvær for så lidt.

enig mht valgte brugernavne. jeg har selv et hieraki a passwords jag bruger. Et lille nemt et til alle de steder hvor det er ret ligemeget (fx her) op til en 16-bogstav komplext et til banken.
men med randomgenereret pasword skrider logikken da. hvorfor bliver det sikrere af at være unikt ?

_darkstar_ >> Nu er forskellen på os to, at jeg jo faktisk har testet - og ikke lader mig forvirre af en fejlberegnet 'faktor 8'. Prøv lige igen  ;o)

En test medførte fire duplikater, så deeeeeeeet .....  :)
Men for min skyld må du give samme password til alle  ;o)
/mvh

oleboles nr 2 er ikke hashing, stadig lineær. og linien:
  $passwords .= $tmpPass."|";
kan gå hen og blive gevaldig dyr. hvergang skal der allokeres nyt dataareal til strengen og det gamle frigives.

eller ver det MIN der er 8 gange sløvere. Utænkeligt :-))

Nej, det er zq ikke hashing ... det plejer jeg at lade mine lunger tage sig af  *-\

"... hvergang skal der allokeres nyt dataareal til strengen og det gamle frigives"? Er du nu ikke ude i en temmelig akademisk disput i forhold til den aktuelle opgave?
Scriptet skal formodentlig køre én gang i verdenshistorien - og det gør det på omkring 15 sekunder på min maskine (dog har jeg ikke indsat i DB)  :)
/mvh

olebole>>> Nu ved jeg tilfældigvis hvor gevaldigt mange points du har her på Eksperten og du er derfor også i mine øjne lidt af et ikon. Vil du virkelig påstå at du mener at det du skrev ovenfor er god kodestil?

Tænk på at du giver det videre til andre små mini-Olebole-aspiranter. Idéen med at katenere strengene er fuldstændig vanvittigt.

At scriptet kun skal køre én gang synes jeg er et fair argument for at bruge dit forslag alligevel, men det skal da ikke publiceres her på Eksperten hvor der sidder en fantasillion newbies og kopierer til højre og venstre.

...og iøvrigt vil jeg holde fast i min faktor 8. Med midnre at strpos i php benytter en modificeret version af KMP-algoritmen, hvilket jeg har svært ved at tro.

1. Nu er det jo lykkeligvis ikke dig, der skal censurere indlæg på E  :)
Naturligvis skal alle 'små mini-Olebole-aspiranter' også lære de små quick 'n' dirty løsninger, man bruger i den slags situationer. Skal man bruge 15.000 passwords i sin database, kommer man vist aldrig til at kunne leve af det, hvis man sidder og bruger sin tid på at spekulere over 'god kodeskik'.
Der gælder det om i en fart at få fyldt skidtet ind i en tabel, så man kan bruge sin tid på at skrive noget til nettet, der forhåbentlig er langt bedre, end hvad man normalt ser  :)

2. Hvad angår din faktor 8, kan du jo teste i stedet for at gætte. Bruger du in_array går scriptet naturligvis dødt (erkendt: det var et elendigt forslag). Bruger du en streng, afvikler det indenfor få sekunder ... prøv  ;o)
/mvh

Lidt støtte til ole. strengsøgningen gørdet grumme meget hurtigere også med den konkatenering (som jeg nok mest er opmærksom på fordi det er noget af et standardexempel i Java om hvordan StringBuffer er hutigere end String:-))

Med 10000

olebole 1:    133.51730203629 sekunder  in_array
olebole 2:    5.7326520681381 sekunder  strpos

Men jeg skal da ikke undlade at blære mig af at det associative array stadig er flere gange hurtigere :-))
jakoba 1:      0.8333740234375 sekunder  hashing

mvh JakobA

At jeg skulle være interesseret i at censurere dig, Ole, tolker jeg som en total overreaktion fra din side og vil egentlig ikke kommentere yderligere.

Jeg påstår ikke at in_array var smart. Selvfølgelig undrer det mig at den er så langsom sammenlignet med med streng-tingen, men bundlinien er stadigvæk at det er noget værre hackeri og jeg synes at det er skidt at lære folk den slags.

Hvis jeg skal ansætte en programmør (og tro mig - jeg har ansat en del), så beder jeg om lov til at se noget kode som vedkommende har lavat igennem. Ser jeg sådan noget som det du har lavet ovenfor ville det i praksis betyde et lønhop fra 22.000 til 18.000 om måneden.

_darkstar_ >>
1. At du ikke ser en smiley (og kan tolke den), undrer mig, hvis du i øvrigt beskæftiger dig med WWW. De manglende kommentarer taler dog til din charmes fordel  :)

2. Pointen skal åbenbart bukkes i meterhøjt neon. Der er tale om, at manden skal have fyldt noget i en DB i en offline-situation - dette er ikke noget, der skal bruges i en 'skarp' situation.
Møbelsnedkeren bygger jo heller ikke et malerstillads i poleret mahogni, når han skal kridte loftet hjemme i stuen. Møbelsnedkerlærlingen bør vel også lære, at der er forskel på, hvad en kunde skal have og hvad man lige skal bruge i en håndevending  :)
Naturligvis skriver du intet sted, in_array er smart ... det er der vist heller ingen andre, der gør - og der er heller ikke nogen, der påstår, du har påstået det.

3. At du kunne finde på at sætte lønnen ned med 4.000, fordi en medarbejder har lavet dette på sin lokale maskine - og det i øvrigt ikke skal bruges til andet, end at generere nogle passwords - viser med al ønskelig tydelighed, at man ikke behøver være en god leder, blot fordi man har ansat mange.
Ydermere kan det jo undre, da der her må være tale om en medarbejder helt uden erhvervserfaring, siden han kun kan vente 22.000 - uden den slags 'utilgiveligheder'.

jakoba >> Der er ingen somhelst tvivl om, hashing er langt hurtigere. Hastighed og performance er dog stadig ikke relevant i dette tilfælde  ;o)
/mvh

_darskstar_ >> Hvis du skulle have en åbning er jeg yderst interreseret. Det er efterhånden lovlig længe siden jeg har fået pengører for det. 18000/m er fint og du kan endda sikkert få AF til at betale de fleste af dem.

mvh JakobA

olebole>>>

1. Ironi virker så skidt på nettet og specielt overfor mig. Jeg fangede den ikke.

2. Dårlige vaner er dårlige vaner.

3. Det kommer vel an på hvilken virksomhed man arbejder for. Og iøvrigt ville en kommentar om at den del af koden måske kunne gøres bedre med <blink>HASHES</blink> rette op på sagerne.

...og iøvrigt - siden at vi fortsætter ud af dette sport - min virksomhed gik konkurs i starten af 2002. Jeg vil lade det være op til læseren at spekulere om det skyldes at jeg var en dårlig leder.

sport -> spor.

Dårlige vaner er ved Gud dårlige vaner ... det kommer vi aldrig til at diskutere.
Nu kræver det jo blot, at en ting bliver gentaget ofte, før det bliver en vane. Jeg kan se problemet, hvis der skal genereres 15.000 passwords flere gange om ugen. Da det nok er vildt uaktuelt, er din proportionssans for mig at se et langt større problem  ;o)

add 3: Nej - dårlige ledere er dårlige ledere ... uagtet, hvilket firma eller afdeling de leder.
En leder, der går op i, om en medarbejder har opnået at lave et stykke upåklageligt arbejde ved at lave dette eller hint lokale 'hack', har et væsentligt problem med sit fokus og er ikke, hvad jeg forstår ved en god leder.
Hans fokus burde ligge i at holde skuden ovenvande og sikre kvallitet i resultatet - i stedet for at risikere at sænke den med lokalt flueknepperi og andet tidsspilde.

Det forekommer mig dog, vi ikke bliver enige - så EOD herfra  :)
/mvh

"sikre kvallitet i resultatet"

Den vil jeg lige lade stå et øjeblik :)

Egentlig havde jeg jo lovet, jeg ville holde kæft, men for din egen skyld, vil jeg dog lige kommentere den sidste:
Har du spekuleret over, du dermed også lader dine manglende evner til at læse indenad (måske endda en alt for overbærende tolkning) til skue for alverden ... ikke blot et øjeblik - men så længe Eksperten eksisterer?

Ja, sikre kvallitet i _resultatet_ ...!
Jeg skrev netop 'i resultatet'. Det burde da ikke være den store intillektuelle udfordring at forstå ... specielt ikke, da du formår at gentage det.

Det kan da ikke undre nogen, dit firma ikke længere eksisterer, hvis du på den måde har siddet og pillet i dine medarbejderes 'mellemregninger' - og samtidig bare ikke _vil_ forstå, hvad folk siger/skriver til dig.

Havde du bare tænkt det mindste over, hvad jeg skrev, ville du også vide, at jeg jo netop ønsker, man skal sørge for upåklagelig kvallitet i _resultatet_ ... altså det, der skal ud af huset.
Det burde efterhånden stå soleklart for enhver, det ikke er, hvad der er tale om her.

olebole>>> Vi er vidst ikke enige om hvad definitionen på ordet "resulatet" er.

Jeg mener at "resultatet" er et system der virker og som andre kan bygge videre på. Det kræver at koden er skrevet så "straight" som overhovedet muligt uden hacks og andet lir.

Som jeg skrev igen ovenfor - det kommer an på hvad det er for en virksomhed man arbejder for. Webbureauer og reklamebureauer vil helt sikkert finde din tilgang meget attraktiv. Jeg tror på den anden side ikke at folk som f. eks. Navision eller Mærsk Data ville blive glade for den.

Hmm jeg har fået mit svar og i kan på ingen måde bedømme hvad jeg skal bruge det til.

Men jeg kan sige at det virker efter hensigten, og spare mig for et sikkerhedshul, ved at brugerne skal oprette sig selv i vores system.

jeg er ligeglad med hvorlangt tid det tager og generer disse brugernavne og password, bare det bliver gjort, da vi i snit opretter 200 - 500 bruger på en uge, og vi forventer at oprette min. 52.000 bruger frem til 2005.


Mvh.
asdl

_darkstar_ >> *ROTFLMAO* At debattere med dig er zq da som at drukne en prop i en spand vand med én finger  :D

Hvad du mener, ordet 'resultatet' dækker i alle mulige fiktive situationer, kan vel ikke være af synderlig interesse for nogen.
I dette tilfælde er 'resultatet', at der ligger 15.000 passwords i en DB ... hvordan de er kommet der, kan i den forbindelse være rystende underordnet.
Så vidt jeg har forstået, skal der bygges videre på de genererede passwords - ikke på scriptet, der genererede dem.

Jeg er helt enig i, der er stor forskel på, hvad forskellige firmaer finder attraktivt hos en medarbejder/leder.
Jeg kan dog ikke forestille mig andet end enmandsbetjente pølsevogne, hvor man kan bruge en medarbejder, der:
1. i _den_ grad nægter at læse, hvad andre skriver.
2. ser bort fra - eller fordrejer - alle argumenter for under alle omstændigheder at få ret.
3. snuser rundt for at checke, om der nu er små fedtpletter på andre medarbejdernes kladder.

Hvad angår Mærsk og Navision, er det nok værd at huske på, at A.P. Møller (og dermed Mærsk) koncernens motto alle dage har været: "Rettidig omhu" ... ikke: "Utidig og misforstået omhu" eller "Utidig snagen og tidsspilde".