Den frie kafeen

[NgZ]

CUPS, som jeg HATER deg,

avskyr den du eeeeeee

drar gjerne til helvte

hvis blir grillet meeeed.

 

Også hater jeg en fordømt nisse fra Fedora som har patchet printer-biten av gnome-control-center slik at det ikke lengr er muig å bruke den til å legge til nettverksskrivre på noen anen disto enn Fedora, fordi den ser etter en dynamisk brannmur-greie, som kun finnes til Fedora. Feilmeldingen skal visstnok kun vises dersom enkelte protokoler er sperret av en brannmur, men i føle bugrapporten hos Ubuntu, er det dessverre ikke tilfelle. (Ubuntu har imidlertid merket bugen som low i, forståelig nok ettersom deres unity-verktøy for samme oppgave,som er standard, virker.)

 

Installerte system-config-printer (Python-applet), men det kan virke som om Arch-pakken er bugget, med mindre det er meningen at PyGtk-programmet ikke skal inkludere noe du kan launche som et program med python. Ingen .desktop-fil eller noe heller.

 

La til slutt inn KDE (minus kdepim naturlig nok mtp tidligere erfaringer) for å legge til nettverksskriver der, men først nektet det meg tilgang og klaget på manglende CUPS-access, selv om jeg er i guppen lpadmin som er konfigurert som printeradmin i cupsd.conf. I tillegg nektet webgrenesnittet å fungere. Ny konfigrasjonsfil hjalp ikke. Rnsket ut cup-pakkene inkl. setting, reinstallerte.

 

Samme resultat i KDE-verktøyet- Rebootet flere ganger, no dice.

 

Nå, når jeg har kommet hjem, fungerer det a seg selv. Uforklarlig.

 

CUPS, I HATE YOU!

 

jaja, fikk ihvrtfall summet meg til å gi KDE en ny sjanse, selv om jeg hold meg unna kdep en stund.

 

Første irritasjonsmoment: ntworkmanager fungerer rett og slett ikke som det skal, når nm-applet kjøres i KDE. Nekter å koble se til nettverk på universitet o.l., et problem jeg aldri har når jeg kjørr ren cinnamon/gnome sssion/dektop. Veldig, veldig merkelig. Samme resultat med network manager-appleten til KDE og.

[RattleBattle]

Unnskyld mitt dumme spørsmål om hashing med eksempel:

 

mysql> insert into example (id, data) values ('2', MD5('passord'));
Query OK, 1 row affected (0.00 sec)

mysql> select * from example;
+------+----------------------------------+
| id   | data                             |
+------+----------------------------------+
|    2 | 56f491c56340a6fa5c158863c6bfb39f |
+------+----------------------------------+
1 row in set (0.00 sec)

mysql> insert into example (id, data) values ('77', MD5('passord'));
Query OK, 1 row affected (0.00 sec)

mysql> select * from example;
+------+----------------------------------+
| id   | data                             |
+------+----------------------------------+
|    2 | 56f491c56340a6fa5c158863c6bfb39f |
|   77 | 56f491c56340a6fa5c158863c6bfb39f |
+------+----------------------------------+
2 rows in set (0.00 sec)

 

Jeg har, som dere sikkert skjønner, lagt inn to rader med passordet "passord" med MD5-hash. Det jeg stusset litt på, selv om det er samme passordet, er at hash-key som blir generert er den samme. Er dette normalt?

Endret 14. mars 2012 av RattleBattle

[endrebjo]

Det er helt riktig at hashen blir den samme hvis du hasher samme nøkkel. Hvordan skulle du ellers klare å sjekke om passordet som sendes fra brukeren er lik det som er lagret i databasen? Det du blant annet oppnår med hashing er at det opprinnelige passordet (nøkkelen til hashen) er veldig vanskelig å finne, så databasen blir litt tryggere i hendene på uvedkommende.

 

Les om hashing, og bruk helst SHA2 i stedet for MD5.

Endret 14. mars 2012 av endrebjo

[RattleBattle]

Det er helt riktig at hashen blir den samme hvis du hasher samme nøkkel. Hvordan skulle du ellers klare å sjekke om passordet som sendes fra brukeren er lik det som er lagret i databasen? Det du blant annet oppnår med hashing er at det opprinnelige passordet (nøkkelen til hashen) er veldig vanskelig å finne, så databasen blir litt tryggere i hendene på uvedkommende.

 

Les om hashing, og bruk helst SHA2 i stedet for MD5.

Takk, skal sjekke det ut.

 

Det kan nok være vanskelig hvis man skal hacke en spesifikk bruker, men hvis man vil ha passordet til noen tilfeldige av for eksempel noen tusen brukere, er det forsåvidt bare å kjøre en select setning som dette:

select * from example where data=MD5('passord');

[Lycantrophe]

Om passordet er lagret i MD5-hash i en database søkbar av hvem som helst.

 

Som ikke bør skje.

[xaco]

Unnskyld mitt dumme spørsmål om hashing med eksempel:

 

mysql> insert into example (id, data) values ('2', MD5('passord'));
Query OK, 1 row affected (0.00 sec)

mysql> select * from example;
+------+----------------------------------+
| id   | data                         	|
+------+----------------------------------+
|    2 | 56f491c56340a6fa5c158863c6bfb39f |
+------+----------------------------------+
1 row in set (0.00 sec)

mysql> insert into example (id, data) values ('77', MD5('passord'));
Query OK, 1 row affected (0.00 sec)

mysql> select * from example;
+------+----------------------------------+
| id   | data                         	|
+------+----------------------------------+
|    2 | 56f491c56340a6fa5c158863c6bfb39f |
|   77 | 56f491c56340a6fa5c158863c6bfb39f |
+------+----------------------------------+
2 rows in set (0.00 sec)

 

Jeg har, som dere sikkert skjønner, lagt inn to rader med passordet "passord" med MD5-hash. Det jeg stusset litt på, selv om det er samme passordet, er at hash-key som blir generert er den samme. Er dette normalt?

 

Det er helt normalt ja, det er derfor man gjør dette.

[endrebjo]

Det kan nok være vanskelig hvis man skal hacke en spesifikk bruker, men hvis man vil ha passordet til noen tilfeldige av for eksempel noen tusen brukere, er det forsåvidt bare å kjøre en select setning som dette:

select * from example where data=MD5('passord');

Derfor er det god praksis å også salte passordet på en litt innviklet måte før det hashes/lagres. Gjerne med et unikt salt for hver bruker. Og kanskje du hasher passordet, salter hashen, og lagrer hashen av den saltede hashen?

[RattleBattle]

Så et PHP-eksempel med sha1+salt. Så greit og forståelig ut, men regnes det som greit med mda5+salt? Er sikkert ikke så veldig stor jobb, men ser at MySQL-versjonen som følger med Ubuntu 10.04 har enablet støtte for SSL.

 

Her er PHP-eksempelet:

http://snippets.dzone.com/posts/show/12523

Endret 14. mars 2012 av RattleBattle

[efikkan]

Eksempelet er ikke dårlig, så lenge saltet ikke er tilstrekkelig stort. Hva med å ha noe som henter ut fra /dev/random x antall tegn? (kan bli tregt)

 

MD5 + salt går helt fint, men det spørs heller om MD5 er trygt nok, det tar tross alt ikke så lang tid å knekke.

 

Kryptert forbindelse (SSL) må du ha ja.

Endret 14. mars 2012 av efikkan

[endrebjo]

Bruk SHA2 når du har SHA2 tilgjengelig. Er ikke noe vits i å bruke MD5 når du har SHA2 tilgjengelig. Det like lett å bruke SHA2 som MD5.

 

Fra Wiki:

US-CERT now says that MD5 "should be considered cryptographically broken and unsuitable for further use."[9] and most U.S. government applications now require the SHA-2 family of hash functions.[10]

[RattleBattle]

Eksempelet er ikke dårlig, så lenge saltet ikke er tilstrekkelig stort. Hva med å ha noe som henter ut fra /dev/random x antall tegn? (kan bli tregt)

 

MD5 + salt går helt fint, men det spørs heller om MD5 er trygt nok, det tar tross alt ikke så lang tid å knekke.

 

Kryptert forbindelse (SSL) må du ha ja.

Tar nok noe annet random enn tid, ja. Det finnes mange måter å få det til i PHP.

 

Bruk SHA2 når du har SHA2 tilgjengelig. Er ikke noe vits i å bruke MD5 når du har SHA2 tilgjengelig. Det like lett å bruke SHA2 som MD5.

 

Fra Wiki:

US-CERT now says that MD5 "should be considered cryptographically broken and unsuitable for further use."[9] and most U.S. government applications now require the SHA-2 family of hash functions.[10]

Skal se på det. Antart at Ubuntu 12.04 eller nyere Debian kanskje har MySQL-versjon som støtter det ut av esken. SHA1 fungerte fint i 10.04 i alle fall.

 

Takker til alle som har hjulpet til. :-)

[Sokkalf™]

Hashen lagres jo bare i databasen som en tekststreng, så databasen i seg selv behøver ikke å "støtte" det.

[RattleBattle]

Det har du selvfølgelig helt rett i. Tenkte ikke så langt når jeg drev med nesa rett i MySQL... ;-)

[NgZ]

Ang. salting: bruk gjerne bestemte tegn fra brukerens brukernavn og passord. Da får du en unik salt som heller ikke lagres noe sted i databasen, så hele databasen kan bli stjålet uten fare, så lenge de ikke knabber med innloggingsphpkoden.

 

Ingen cups-sympati?

[Lycantrophe]

Tjah, cups + ipp funker rett ut av boksen her.

[Del]

CUPS funker fint her også.

[efikkan]

Ang. salting: bruk gjerne bestemte tegn fra brukerens brukernavn og passord. Da får du en unik salt som heller ikke lagres noe sted i databasen, så hele databasen kan bli stjålet uten fare, så lenge de ikke knabber med innloggingsphpkoden.

 

Ingen cups-sympati?

Ja, men det hjelper deg bare så lenge teknikken du bruker for generering av salt er hemmelig, ideelt sett bør det være basert på noe som brukeren/hackeren ikke kan se. Det er ikke uvanlig å bruke brukernavn, e-post eller lignende som salt. Hvis jeg har en testbruker på den stjålne databasen så er det ikke vanskelig å teste ut vanlige kombinasjoner av md5(password+username) osv. Da står og faller denne ekstra "sikkerheten" på om noen spekulerer ut teknikken din.

 

Se for deg et tredje alternativ med tilfeldig genererte salt i en egen database, da trenger du å forsikre deg om at denne databasen er trygg.

[tomsi42]

Ingen cups-sympati?

Nope.

 

Har aldri likt printing på unix/linux, så det holder jeg meg unna.

[hakonvl]

Du har prøvd webgrensesnittet som root?

[JohndoeMAKT]

Saltet skal være av signifikant lengde og helst være produsert av en PRNG og unikt for hver bruker.

 

Med dårlig semi-pseudokode:

 

$user = 'frank';

$salt = hash('sha-512', prng->getSalt());

$hash = hash('sha-512', $pass . $salt);

 

"insert into users (name, password, salt) values ('{$user}', '{$hash}', '{$salt}');"