Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  8 3836
God morgen!
Jeg er i gang med å lage et SSO, altså et felles innloggingssystem for jobben min. Tanken er å lagre brukernavn / passord i en MySQL-database eller lignende, jeg har ikke fått prøvd ut alle mulighetene jeg har helt enda.

Jeg har møtt på en utfordring, og det er at jeg ikke helt vet hvordan krypteringsalgoritmen til Windows / Active Directory fungerer.
Meningen er at passordet til Active Directory-brukerne skal kunne brukes i andre sammenhenger også, f.eks. i et PHP-skript.

Jeg er fra før kjent med hvordan jeg kan lage et kryptert passord med f.eks. SHA512 i et PHP-skript, men tenker også at hvis jeg lagrer passordet i SHA512-format, så vil ikke Windows sin krypteringsalgoritme kunne få det til å stemme med passordet til brukeren, og deretter vil innlogging til Active Directory feile.

Jeg har lest at Windows bruker en egen og komplisert algoritme, så jeg vurderer å kanskje bruke samme algoritme i PHP-skriptene jeg utvikler, slik at dette problemet er eliminert.

Jeg klarer imidlertid ikke å finne ut hvordan dette kan gjøres, ettersom det ser ut til at det også blir lagt inn en salt når passordet opprettes, og at den krypterte versjonen av passordet ikke er den samme hver gang det blir generert. Dette vil da føre til en ulempe i et PHP-skript som skal sammenligne den krypterte hashen i databasen med hashen som blir generert når brukeren forsøker å logge inn via PHP-skriptet.

Det er ikke bare PHP-skript jeg har tenkt å lage dette for, dette skal også kunne brukes i f.eks. Dovecot og være tilgjengelig for senere bruk av evt. nye systemer.

Noen som kan sparke meg i riktig retning? Selvfølgelig, jeg kan nok bruke LDAP-plugins for å autenisere brukere mot Active Directory i seg selv, men jeg vil prøve å holde meg så mye til MySQL som mulig. Akkurat nå prøver jeg meg med å utvikle LDAP helt fra bunnen av med ldapjs og en plugin for MySQL-oppbevaring, men har ikke gjort så mye med det enda, ettersom jeg må forstå hvordan algoritmen til Windows fungerer før jeg evt. kaster bort tiden på å gjøre dette.
Trigonoceps occipita
vidarlo's Avatar
Donor
Kvifor prøver du å hekle di eiga løysing? Og gitt at du ar AD - kvifor skal du ha ein database til med passord? Er det ikkje betre å bruke AD til autentisering da?
Trådstarter
Sitat av vidarlo Vis innlegg
Kvifor prøver du å hekle di eiga løysing? Og gitt at du ar AD - kvifor skal du ha ein database til med passord? Er det ikkje betre å bruke AD til autentisering da?
Vis hele sitatet...
Jeg ønsker å ha full kjennskap til hvordan innloggingen fungerer og ha bedre mulighet til å feilsøke, replikere og vedlikeholde systemet på egen hånd. Der jeg jobber er det ingen rom for dataproblemer, ettersom ingen i de andre avdelingene, f.eks. regnskapsavdelingen, får gjort jobben sin dersom systemet går ned. Altså ganske kritisk at alt skal fungere til enhver tid.

Selvfølgelig, jeg kan bruke AD, men akkurat nå er jeg i en fase hvor jeg ønsker å undersøke hvilken løsning som passer best for oss. Det er ikke uaktuelt å bruke AD sin innlogging dersom jeg lander på at det er det beste for oss. Har du noen tips i forhold til spørsmålet jeg stiller i førstepost?
Trigonoceps occipita
vidarlo's Avatar
Donor
1. Autentisering er vanskelig. Den heimesnekra løsninga di vil garantert ha feil. Gå for etablert protokoll med bibliotek, f.eks. SAML eller Oauth2.
2. Du har AD. Dvs: Gå for AD som sannhetskilde for brukerinformasjon.
3. Ikkje finn opp det jævla hjulet på nytt. Finn ei løysing basert på AD som funker i ditt scenario - f.eks. kan Keycloak autentisere mot AD.

Forøvrig er det totalt illustrerande at du snakker om kjapp hashfunksjon som sha512 for å lagre passord. Bruk funksjon som faktisk er laga for passord, f.eks. scrypt.
Sist endret av vidarlo; 16. mars 2022 kl. 09:28. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Trådstarter
Sitat av vidarlo Vis innlegg
1. Autentisering er vanskelig. Den heimesnekra løsninga di vil garantert ha feil. Gå for etablert protokoll med bibliotek, f.eks. SAML eller Oauth2.
2. Du har AD. Dvs: Gå for AD som sannhetskilde for brukerinformasjon.
3. Ikkje finn opp det jævla hjulet på nytt. Finn ei løysing basert på AD som funker i ditt scenario - f.eks. kan Keycloak autentisere mot AD.

Forøvrig er det totalt illustrerande at du snakker om kjapp hashfunksjon som sha512 for å lagre passord. Bruk funksjon som faktisk er laga for passord, f.eks. scrypt.
Vis hele sitatet...
1: SAML og Oauth2 er kanskje akkurat det jeg ser etter / tenker på å utvikle selv. Jeg har aldri hørt om, eller forstått hva det brukes til, før nå.

2: Det er Samba som er AD-kontrolleren i dette tilfellet, om det har noe å si, men jeg googler meg nok frem til noe.

3: Det jævla hjulet har punktert og blitt makulert, men Keycloak er notert :-)

Det du skriver om SHA512 høres nesten ut som at det i utgangspunktet kanskje ikke skal brukes til passord, har du isåfall eksempler på hva den algoritmen kan brukes til, i og med at det ikke er en reversibel algoritme? Scrypt er noe jeg også har notert og skal se på.
Tastaturkriger
Deezire's Avatar
Du vil virkelig ikke gjøre dette selv. Vi har utviklet vår egen SSO-løsning internt, med et team på ti personer som har holdt på i snart fem år. Vi har et budsjett på mange millioner i året og vi har en brukerbase som er i størrelsesordenen et mellomstort land. Det er ganske bred enighet om at hvis vi skulle gjort det igjen så hadde vi bare basert hele løsningen på KeyCloak. Det er selvsagt noen ganger kjekt at vi har vår egen løsning og relativt enkelt kan gjøre tilpasninger når regelverk eller andre ting plutselig endrer seg, men det er strengt tatt ikke noe som en løsning basert på eksisterende teknologi ikke hadde latt oss gjøre.

Et godt startpunkt er å lese speccen til f.eks. SAML eller OAuth2, og hvis du sitter igjen som dette så burde du ta et hint.

Hvis det er en kritisk tjeneste for firmaet du jobber i så kjøper dere Azure AD fra Microsoft Azure. Det er en bunnsolid løsning, selv til å være fra Microsoft. Da får du Kerberos, OIDC, SAML og alt ut av boksen. Og noen andre tar seg av patchingen.
Trådstarter
Veldig flott, nå er Keycloak satt opp her
Sitat av FailedTech Vis innlegg
Det du skriver om SHA512 høres nesten ut som at det i utgangspunktet kanskje ikke skal brukes til passord, har du isåfall eksempler på hva den algoritmen kan brukes til, i og med at det ikke er en reversibel algoritme? Scrypt er noe jeg også har notert og skal se på.
Vis hele sitatet...
Det er ikke noe galt i å bruke SHA-512 til å lagre passord, så lenge du har gjort noe for å treige den ned (for eksempel pakke den inn i PBKDF2). Ren, stand-alone SHA-512 er, som nevnt, en lynrask hash-algoritme, så den er sårbar for bruteforce-angrep.
(Hashalgoritmer som ikke lengre egner seg til passordlagring, kan for øvrig fremdeles fint benyttes til andre formål, som (integritets-)sjekksummer o.l.)

NIST anbefaler f.eks. PBKDF2 med HMAC-SHA256/512 for bruk av amerikanske myndigheter (som må være FIPS-compliant), men med forbehold om så mange iterasjoner som mulig, og minst 10 000. OWASP anbefaler 310 000 iterasjoner for SHA-256 og 120 000 iterasjoner for SHA-512 i 2021. (Sjekk gjerne ut lenken for mye mer nyttig informasjon om passordlagring!)

For din bedrift, som neppe trenger å bry dere om FIPS, så er det andre algoritmer (Argon2, bcrypt, scrypt, ...) som rangeres høyere av diverse sikkerhetsautoriteter nå. Jeg støtter absolutt bruk av f.eks. Argon2 eller scrypt, så du bør absolutt gå for det! Men SHA-512 skal ikke avfeies helt, altså. Det krever imidlertid at du implementerer det riktig. Det er neppe en korrekt implementert SHA-512 som kommer til å være akilleshælen i det hjemmesnekrede systemet ditt. Det store, røde flagget er å prøve å snekre sammen sitt eget system i det hele tatt.


Nå virker det som du går for ferdiglagde, velutprøvde løsninger, og det synes jeg høres fornuftig ut!
Trådstarter
Sitat av Realist1 Vis innlegg
Det er ikke noe galt i å bruke SHA-512 til å lagre passord, så lenge du har gjort noe for å treige den ned (for eksempel pakke den inn i PBKDF2). Ren, stand-alone SHA-512 er, som nevnt, en lynrask hash-algoritme, så den er sårbar for bruteforce-angrep.
(Hashalgoritmer som ikke lengre egner seg til passordlagring, kan for øvrig fremdeles fint benyttes til andre formål, som (integritets-)sjekksummer o.l.)

NIST anbefaler f.eks. PBKDF2 med HMAC-SHA256/512 for bruk av amerikanske myndigheter (som må være FIPS-compliant), men med forbehold om så mange iterasjoner som mulig, og minst 10 000. OWASP anbefaler 310 000 iterasjoner for SHA-256 og 120 000 iterasjoner for SHA-512 i 2021. (Sjekk gjerne ut lenken for mye mer nyttig informasjon om passordlagring!)

For din bedrift, som neppe trenger å bry dere om FIPS, så er det andre algoritmer (Argon2, bcrypt, scrypt, ...) som rangeres høyere av diverse sikkerhetsautoriteter nå. Jeg støtter absolutt bruk av f.eks. Argon2 eller scrypt, så du bør absolutt gå for det! Men SHA-512 skal ikke avfeies helt, altså. Det krever imidlertid at du implementerer det riktig. Det er neppe en korrekt implementert SHA-512 som kommer til å være akilleshælen i det hjemmesnekrede systemet ditt. Det store, røde flagget er å prøve å snekre sammen sitt eget system i det hele tatt.


Nå virker det som du går for ferdiglagde, velutprøvde løsninger, og det synes jeg høres fornuftig ut!
Vis hele sitatet...
Vel, grunnen til at jeg ikke gikk for ferdiglagde systemer først var faktisk fordi jeg mot all formodning ikke trodde det eksisterte… Dere skal ha en takk for å ha gjort hele greia lettere for meg idag.