security -> shell account en shadow-file

[anoniem]

Dan vraag ik mij ook nog af of de Salt er altijd op de zelfde manier ertussen staat, of dat dat ook nog weer ergens van afhaneklijk is, zodat de Salt zelf ook moeielijk is te vinden.

[anoniem]

Nee. Het staat gewoon altijd op dezelfde plek. De salt zelf is uiteraard wel random. Ik snap niet wat nou het probleem is. Aan de salt heb je namelijk niets als cracker. Dus het heeft ook geen zin dat te verbergen. Zelfs met salt + encrypted/hashed wachtwoord kun je het oorspronkelijke wachtwoord niet achterhalen. Daarom is de hash one-way.

[anoniem]

Geen probleem, puur willen begrijpen. :wink:

[anoniem]

Ack ;).

[anoniem]

[quote:5be14d2b76="danieldk"]Ja, de salt staat er onversleuteld tussen. Dus in de string heb je de "plain" salt en de hashed wachtwoord. Als een wachtwoord gecontroleerd moet worden, wordt het ingevoerde wachtwoord dus eerst geXORed met het salt, en vervolgens gehashed met een one-way hash. Als de resulterende hash gelijk is aan die in /etc/shadow klopt het wachtwoord.[/quote:5be14d2b76] Kijk, dit is duidelijk nu begrijp ik het... Toch nog even deze : [quote:5be14d2b76="danieldk"] Nee. Het staat gewoon altijd op dezelfde plek. De salt zelf is uiteraard wel random. Ik snap niet wat nou het probleem is. Aan de salt heb je namelijk niets als cracker. Dus het heeft ook geen zin dat te verbergen. Zelfs met salt + encrypted/hashed wachtwoord kun je het oorspronkelijke wachtwoord niet achterhalen. Daarom is de hash one-way.[/quote:5be14d2b76] Natuurlijk kun je het wachtwoord niet uit de hash halen. Maar..., wanneer er op de brute-force mannier met dictonary's hashes worden gegenereerd is die saltwaarde onmisbaar lijkt mij. Misschien dat ik wat mis hoor, ben namelijk geen expert op dit gebied :lol: , maar als je de salt waarde hebt, dan kun je de woorden uit een dictonary-file x-or-en met de salt-waarde en met die uitkomst vervolgens gaan brutforce vergelijken. Dat kun je met een simpel scriptje wel voorelkaar krijgen denk ik... Tenminste, ik neem aan dat de md5 encryptie op alle systemen gelijk is ?

[anoniem]

Die salt waarde zul je toch als zodanig nodig hebben om de boel te coderen en te controleren. Dan kun je wel "security through obscurity" bedrijven, maar men komt er toch wel achter waar de salt staat. Sommige systemen gebruiken ook nog DES ipv MD5 (werkt iets anders). Met name voor compatibiliteit als NIS (yellow pages) gebruikt wordt.

[anoniem]

Ok, bedankt voor de duidelijke uileg.

[anoniem]

Hé...ik kom er net achter dat ftp-gebruikers die ik hun shell toegang heb ontnomen niet kunnen ftp'en. Omdat ftp vrij makkelijk is en laagdrempelig (windowsgebruikers) heb ik dus tijdelijk ftp draaien. Om geen onnodig risico te lopen heb ik op jullie aanraden hun de shel toegang ontnomen. Nu blijkt echter dat wanneer ze geen shell toegang hebben, ze ook niet meer ftp toegang hebben ! Ik maakte van de /bin/bash in de passwd file /dev/null en ik heb ook /bin/false geprobeerd. Beide met de zelfde consequenties.

[anoniem]

Ja dat is een bekend probleem met ftp..... heeft ssh ook een shell nodig..... anders zouden ze scp of winscp kunnen gebruiken..... veel veiliger en handiger in het inderhoud.

[anoniem]

Ja...zelf ben ik ook een groot voorstander van ssh, maar het was juist de bedoeling om deze mensen uit de shell te weren ;) Een tijd terug heb ik eens vsFtp gedraaid op een andere pc...als ik het mij goed herinder kon je daar ftp-only users in aanmaken...en het had nog wat handige restricties volgens mij. Maar met de standaard ftp voorziening kun je dit niet oplossen zeker ?