Link alla notizia: http://www.hwupgrade.it/news/sicurezza/schede-video-per-svelare-le-password_23038.html

Brevettata una tecnica che utilizza le schede video per accelerare i tempi necessari alla scoperta delle password

Click sul link per visualizzare la notizia.

ma io non ho capito bene una cosa..... questi brevettano un modo per craccare i pc della gente e nessuno gli dice o fà niente? diemi che ho capito male plz

Pauroso quindi tra un po' avere password a 10 o 20 numeri sarà come avere password monocifra, cioè come non averla

ma io non ho capito bene una cosa..... questi brevettano un modo per craccare i pc della gente e nessuno gli dice o fà niente? diemi che ho capito male plz

Non crackano pc ma algoritmi di crittografia, vengono studiati per scoprirne i punti deboli e le possibile falle, in questo modo li rendono migliori non credi? ;)

Bah, un buon sistema non teme attacchi brute force: ad esempio al quarto o quinto
tentativo andato male introduce un ritardo di 1 secondo che raddoppia per
ogni ulteriore tentativo fallito fatto nella stessa giornata.
(dopo 14 tentativi servono 20 minuti, più di una 20ina di tentivi
"a caso" al giorno non si posson fare).

Se le banche non sono manco arrivate a questo allora farebbero bene
ad assumere dei veri esperti e non dei raccomandati.

Oh mamma, ci mancava il brevetto sul coprocessore!

Pauroso quindi tra un po' avere password a 10 o 20 numeri sarà come avere password monocifra, cioè come non averla
Fuffa, questo vale solo per i sistemi progettati male.
Per quelli fatti bene bastano i tipici 6 caratteri alfanumerici
(per esempio quelli che chiede UNIX).

ma io non ho capito bene una cosa..... questi brevettano un modo per craccare i pc della gente e nessuno gli dice o fà niente? diemi che ho capito male plzQuesti non hanno brevettato un modo per craccare i pc della gente, quello che fanno è già possibile ora, semplicemente con questo sistema si sfrutta meglio la capacità di elaborazione del pc e si velocizza l'operazione...

Poi tu vedi la cosa solo da un punto di vista, a me ad es è capitato più volte di risparmiare parecchio tempo facendo il bruteforce di una password (nel caso specifico la password di un id di Lotus Notes) con un software apposito che non creare da zero un nuovo utente e settare tutti gli accessi necessari.

Le tematiche di sicurezza non possono essere ridotte a una semplice password, qui sta il problema :rolleyes:

si ma ad esempio con XP si frega un filettino che non mi ricordo (letto sui libri di Mitnick) e poi si fa l'attacco bruteforce su quello, tranquillamente a casa nel tuo pc.... poi una volta scoperta la password vai sul sistema con la password sicura...il sistema che dici te funziona solo se agisci direttamente dal mezzo di immissione password predefinito... ma se attacco direttmente i files dove sono contenute le password...

Questi non hanno brevettato un modo per craccare i pc della gente, quello che fanno è già possibile ora, semplicemente con questo sistema si sfrutta meglio la capacità di elaborazione del pc e si velocizza l'operazione...
Ecco appunto, quello che hanno sempre fatto i coprocessori.

Complimenti al femtocefalo di turno dell'ufficio brevetti, non era facile accettare una cosa simile. Neanche negli USA.

L'utilizzo di un coprocessore (perché di questo si tratta) _non_ dovrebbe essere brevettabile, anche se la cosa non mi stupisce (ormai si brevettano pure i protocolli...)
Per chi crea allarmismi: sono richieste decine di anni per portare a termine un attacco esaustivo su una chiave aes 256 bit, utilizzando una gpu il tempo scenderebbe a qualche anno. Direi che si può stare abbastanza tranquilli, non trovate? Non tutti gli algoritmi sono deboli come quelli che utilizza la MS in windows...

Edit: nel frattempo che postavo avete scritto una pagina intera :) mi sembrava strano che ilsensine non avesse ancora postato... :asd:

lol @ femtocefalo!

si ma ad esempio con XP si frega un filettino che non mi ricordo (letto sui libri di Mitnick) e poi si fa l'attacco bruteforce su quello, tranquillamente a casa nel tuo pc.... poi una volta scoperta la password vai sul sistema con la password sicura...il sistema che dici te funziona solo se agisci direttamente dal mezzo di immissione password predefinito... ma se attacco direttmente i files dove sono contenute le password...

beh anche linux conserva le password in un unico file (/etc/passwd o /etc/shadow) o ricordo male?

C'è una valutazione che va oltre al livello di " massaia informatica " da parte di Jeff Atwood
http://www.codinghorror.com/blog/archives/000986.html

Edit: nel frattempo che postavo avete scritto una pagina intera :)
Stai accedendo al forum con telnet? Puoi anche usare links sai :asd:

beh anche linux conserva le password in un unico file (/etc/passwd o /etc/shadow) o ricordo male?
shadow contiene solo gli hash delle password, potrebbero essere utili ma comunque non è leggibile dagli utenti normali.
Credo bene che anche windows conservi gli hash in posti sicuri.

Bah, un buon sistema non teme attacchi brute force: ad esempio al quarto o quinto
tentativo andato male introduce un ritardo di 1 secondo che raddoppia per
ogni ulteriore tentativo fallito fatto nella stessa giornata.
(dopo 14 tentativi servono 20 minuti, più di una 20ina di tentivi
"a caso" al giorno non si posson fare).

Se le banche non sono manco arrivate a questo allora farebbero bene
ad assumere dei veri esperti e non dei raccomandati.

Lo fanno ma qua non si tratta di calcolo al login, diciamo che sul sistema tu puoi (dove puoi) accedere alla password cifrata e tramite calcolo brute force ottieni la password. brute force codifica tutte le combinazioni di caratteri finche la codifica non corrisponde alla password cifrata, e ci vogliono giorni o mesi o anni. Stesso discorso per zip e rar, provi le combinazioni finchè non ti ritrovi con dei dati in chiaro che hanno senso secondo il CRC depositato sullo stesso file.

si ma ad esempio con XP si frega un filettino che non mi ricordo (letto sui libri di Mitnick) e poi si fa l'attacco bruteforce su quello, tranquillamente a casa nel tuo pc.... poi una volta scoperta la password vai sul sistema con la password sicura...il sistema che dici te funziona solo se agisci direttamente dal mezzo di immissione password predefinito... ma se attacco direttmente i files dove sono contenute le password...
? Se il file è fatto bene, non trovi caratteri riconoscibili
(il file codifica tutto tranne i separatori tra una password e l'altra,
o usa separatori che non siano prevedibili a priori, in modo che
tu non possa aggrapparti a niente di conosciuto a priori)
e quindi se anche tu sapessi l'algoritmo che codifica il file di password,
potresti usare quel file solo in catena col servizio stesso, cioè come fosse
un dizionario (ugualmente non ne caveresti un ragno dal buco là
dove il massimo numero di accessi falliti ad un account è 20 al giorno,
ti basterebbero "solo" 100'000 giorni invece che 2 miliardi....).
Del resto 62 caratteri (maiuscole, minuscole e cifre) ^6 = 56'800'235'584 combinazioni,
a 20 al giorno si fa come i computers di Douglas Adams (che dopo 42
generazioni a malapena ricordano la domanda iniziale... se la sanno).

Discorso diverso per i files pdf/rar codificati con password, lì il brute force
è possibilissimo e questo metodo può pure servire a qualcosa, a patto di poter
sapere prima qualche dettaglio sul file che si vuole aprire (ad esempio l'header dei
files contenuti, o la ricorrenza continua del carattere spazio in caso di files di testo, etc.etc.).

il timing introdotto per immetere una password serve a poco...in quanto quelli che devono forzare un sistema lo fanno tramite imagine ram....
non parliamo dei sistemi di accesso online ovviamente....
ma di crackare una pass di un computer fisso....
il grosso problema è che oggi molti dati sono crittografati e questo è un problema per chi come gli esattori dello stato vogliono verificare i conteggi....

ma l'unica soluzione per proteggere la propria privacy è utilizzare un metalinguaggio. è l'unica soluzione....
la crittografia ormai serve a poco.........
quindi W i metalinguaggi....sono i nuovi sistemi di operare sul lato della protezione dei dati...
non esiste altro metodo purtroppo....qualunque metodo basato su di un algoritmo definibile è ormai crackabile.....

con i metalinguaggi non serve ne' la forza bruta ne l'analisi dei sistemi....
.....devono conoscere la lingua.....e se qualcuno non gliela insegna......stanno freschi....
proteggere la propria privacy al giorno d'oggi è importante.....

Hanno "ricompilato" un password cracker usando le librerie CUDA.
Prima o poi doveva succedere.

Anche una società di Antivirus (Kaspersky credo), ha già sviluppato il codice per la scansione antivirus, usando una 2900XT.
Ne parlava The Inquirer qualche tempo fa'.

Credo bene che anche windows conservi gli hash in posti sicuri.

non sono proprio sicuri :(

ophcrack cerca l'hash della password e usando le rainbow tables la ricava in pochissimo tempo (minuti, alla peggio ore) :eek:

Stai accedendo al forum con telnet? Puoi anche usare links sai :asd:
Mai! links non è abbastanza geek :p
Il problema vero sono i tab: ne apri mille e poi scopri che la pagina che hai in cache è di mezzora prima :asd: :doh:

ma ha ancora senso il brute force? già un paio di anni fa lessi di un matetico russo che aveva messo appunto un modello matematico che gli pervetteva, in meno di un ora, di scovare una chiave a 20 caratteri! il tipo venne arrestato dall' fbi appena sbarcato negli state ove si recava per un seminario... chissa che fine a fatto!

non sono proprio sicuri :(

ophcrack cerca l'hash della password e usando le rainbow tables la ricava in pochissimo tempo (minuti, alla peggio ore) :eek:

se hai accesso fisico alla macchina, le password servono ben a poco (almeno di file system crittati), avviando da una distro live puoi avere il file delle pass di win sia il file shadow di linux, la difficolta' e' la stessa...
Poi se parliamo di come viene generato l'hash delle password, beh allora il caso e' diverso.
QUelle linux non dovrebbero essere craccabili con dei rainbow attack (a differenza di quelle di windows) per via che le password sono encodate con dei salt (dei pezzettini generati a caso)...

non sono proprio sicuri :(

ophcrack cerca l'hash della password e usando le rainbow tables la ricava in pochissimo tempo (minuti, alla peggio ore) :eek:


Vero, ma la procedura di crack di un md5 attraverso rainbow table impiega in genere tempi nell'ordine di qualche secondo...

Filmato_esempio (http://www.securitydistro.com/index.php?option=com_content&task=view&id=89&Itemid=32)

Piuttosto sono felice che si inizi a utilizzare le gpu per i calcoli in virgola mobile... hanno un potere computazionale elevatissimo, grazie alla banda e al parallelismo, speriamo che presto si arrivi a un framework di programmazione che li sfrutti a dovere e non con qualche accrocchio manuale

Il punto è che le password di XP sono crittate con un algoritmo penoso. Tanto per fare un esempio il tempo per creccare una password di 10 caratteri è lo stesso necessario per craccarne una di 14 (a meno che non si sappia a priori la lunghezza della password). Da 7 a 8 o più caratteri, il tempo necessario raddoppia (il buon xp spezza le password in due tronconi da 7 caratteri, insomma) inoltre conserva insieme all'hash delle password, l'hash delle password con i caratteri TUTTI MAIUSCOLI, per questioni di retrocompatibilità. E i sistemi di attacco bruteforce ringraziano. Tornando in topic: a quanto ho letto ieri su slashdot, il sistema di cui si parla dovrebbe diminuire i tempi di un fattore 25 circa, che vuol dire, ragionando a spanne, che dovete considerare le password (esclusivamente alfabetiche) più corte di un carattere. Nulla di grave, insomma.

allora: l'algoritmo di elcomsoft fa bruteforcing. se questo è tutto quello che sanno fare, allora troppo idioti per fare danni.
il bruteforcing ha complessità lineare, mentre la password ha complessità esponenziale rispetto al numero di caratteri. se la GPU scandisce, diciamo, 200milioni di password al secondo, e io ho una password alfabetica (maiuscole più minuscole) di 13 caratteri, lo stupendo cracking con gpu ci mette 9667810 ANNI a scoprirla.

il timing introdotto per immetere una password serve a poco...in quanto quelli che devono forzare un sistema lo fanno tramite imagine ram....
non parliamo dei sistemi di accesso online ovviamente....
ma di crackare una pass di un computer fisso....

In che modo potrebbero bypassare il check con un'immagine in Ram scusa?
A parte che ricaricare l'immagine richiede comunque tempo
(mettiamo una decina di secondi), e che usura l'hard disk usarla
continuamente (100'000 accessi sono ad esempio 277 ore di accesso
continuato al disco), ma se non hai accesso al sistema come diavolo la fai
e dove diavolo la scrivi l'immagine della ram?

Un conto è poter mandare un programmino da 1-2Kb dentro la GPU,
altro conto è poter salvare dai 200 ai 500 mega di RAM da qualche parte e
poi poterla ricaricare a piacere in un sistema di cui non hai l'accesso
(almeno su Linux servono i permessi, non so se Windows sia il solito
colabrodo... :rolleyes: ).

Se sapessero come intervenire sul check gli basterebbe far sì che le
password errate fossero considerate valide (il classico metodo delle crack),
e quindi col brute force non ci farebbero un tubo, ma in questo caso nulla
può reggere, manco i metalinguaggi.

Mai! links non è abbastanza geek :p
Il problema vero sono i tab: ne apri mille e poi scopri che la pagina che hai in cache è di mezzora prima :asd: :doh:

Ah, il problema non è che da links devi per forza usare un proxy per avere
un "ponte", mentre con telnet puoi raggiungere il forum in perfetto
anonimato passando da una decina di server diversi (già che vai lento...)?

News interessante, vorrà dire che si studieranno nuovi sistemi di protezione.

Ah, il problema non è che da links devi per forza usare un proxy per avere
un "ponte", mentre con telnet puoi raggiungere il forum in perfetto
anonimato passando da una decina di server diversi (già che vai lento...)?
Ma LOL
Se non si fosse capito quella di ilsensine era solo una battuta, se devo navigare su hwupgrade utilizzo konqueror :doh:

non sono proprio sicuri :(

ophcrack cerca l'hash della password e usando le rainbow tables la ricava in pochissimo tempo (minuti, alla peggio ore) :eek:
Sì ma come fa ad ottenere l'hash? Dovrebbe essere inaccessibile per i profili utente con accesso limitato.

Beh interessante notizia. Comunque per bypassare le protezioni di accesso di XP ed ottenere l'accesso a qualunque sistema protetto bastano i root kit che in giro ci sono da parecchio!!!

Per quanto riguarda l'aspetto legale è perfettamente legale.
Io ho dovuto usare un root kit su un pc in ditta perchè la password è andata persa (cambiata dopo 20 giorni ed il tipo non se la ricordava). In questo caso non si viola nessuna legge.

Se lo usi per scopi illeciti... Beh... Anche una stilografica se la pianti in gola ad uno diventa un'arma... Ma non per questo chi l'ha progettata è colpevole di qualcosa!!!

Ma LOL
Se non si fosse capito quella di ilsensine era solo una battuta, se devo navigare su hwupgrade utilizzo konqueror :doh:
Opsss.... anche tu. Ora che ci guardo però il mio può fingersi Lynx,
Googlebot o persino wget, ma niente telnet. Peccato, era un'idea :Prrr:

http://www.kaspersky.com/safestream

come si diceva prima le gpu servono a molto ehehehe

Opsss.... anche tu. Ora che ci guardo però il mio può fingersi Lynx,
Googlebot o persino wget, ma niente telnet. Peccato, era un'idea :Prrr:
Al contrario con telnet puoi fingerti IE7 :asd:

Sì ma come fa ad ottenere l'hash? Dovrebbe essere inaccessibile per i profili utente con accesso limitato.

non mi ricordo come faceva a trovarlo (l'avevo letto da qualche parte) :(

se non mi sbaglio NON dovrebbe funzionare solo sugli intel a 64 bit perchè non permettono di ricavare l'hash (però non ne sono sicurissimo).

io sinceramente non capisco dove è la notiziona..mi spiego meglio.. esistono gia sul mercato macchine dedicate a test di VA (vulnerability assessment e la maggior parte tutte con OS bsd like) che sfruttano schede accelleratrici che manco a farlo apposta (l'ultima che ho aperta) montava su il chipset da loro chiamato L.u.n.a ..ma che rimuovendo il dissi ti trovi faccia a faccia con un fantastico "Nvidia 6800" e son sicuro che non viene sfruttato per fini grafici anzi.
Penso che cmq sarebbe na figata poter sfruttare in maniera piu nobile questi gioiellini di GPU per altre operazioni ..tipo dare una mano all'os quando l'hw in uso soccombe per mancanza di velocita o risorse cpu...imho ovviamente . :rolleyes:

io sinceramente non capisco dove è la notiziona..
Nel brevetto concesso dall'aquila di turno

Penso che cmq sarebbe na figata poter sfruttare in maniera piu nobile questi gioiellini di GPU per altre operazioni
nvidia infatti ha cominciato a rilasciare strumenti in proposito.

Certo se i geni concedono brevetti per ogni possibile e immaginabile utilizzo, non andiamo lontano.

...mi era sfuggito sto piccolo particolare!!! :mc:
che tristezza ! !
:(

ma se si codificano stringhe con sha1 non è impossibile risalire alla stringa originaria???

( cmq quel video che hanno postato nella shell si legge il sito dell'uni di napoli.. però non mi sono soffermato ad ascoltare, che stanno facnedo? )

bel coraggio a tentare di crakkare con bruteforce una password attraverso il login
anche se non ci fossero ritardi introdotti artificialmente quelli dovuti alla rete sarebbero senza dubbio gia abbastanza :)
a che ti serve avere una gpu a calcolare se devi solo provare la "C ombinazione successiva"e hai tra láltro svatriati secodni per calcolarla?
qua si parla di bruteforce su chiavi criptate per ritirarle fuori in chiaro partendo dal presupposto che il crittato ce l'hai e lo puoi caricare dove vuoi, la GPU a quel punto è usata per crittare in avanti da un dizionaro o sa un generatore sequenziale e matchare sulla chiave gia crittata.

potrebbero anche usarla per computare le ciclicità ma la sostanza è che quella crittata ti serve semrpe averla a disposizione, nonsi parla di login remoto o interattivo.

potrebbero anche usarla per computare le ciclicità ma la sostanza è che quella crittata ti serve semrpe averla a disposizione, nonsi parla di login remoto o interattivo.
Quindi in pratica l'unica utilità del brute force è decrittare i files, CVD.

Ora che ci penso potrebbe anche venire utile per recuperare la chiave
dei films in alta definizione o del fritz chip, bel brevetto...

Bah, le rainbow tables ve le date in faccia con password superiori ai 14 caratteri... Senza contare che usando caratteri non standard già passiamo a tavole da diversi giga.

Per non parlare dell' aggiunta di un "salt" a sua volta cifrato.

"thequickbrownfoxjumpsoverthelazydog" FTW!!! :asd:

Quindi in pratica l'unica utilità del brute force è decrittare i files, CVD.

Ora che ci penso potrebbe anche venire utile per recuperare la chiave
dei films in alta definizione o del fritz chip, bel brevetto...

Per i film in alta definizione è ancora più facile, la maggior parte dei software di riproduzione la legge in chiaro... :rolleyes:

Uno ha detto "vabbè 25 volte in meno non è molto".
Ma sono 25 volte in meno con l'attuale potenza computazionale a disposizione.
Il prossimo anno la potenza elaborativa delle schede video raddoppierà.
Ancora 1,5 anni e possiamo pensare ci sia un altro raddoppio.
I core delle CPU sappiamo già passeranno a 4 nel 2008, e 8 nel 2009. Nel 1012, forse 80.
E vogliamo anche far affinare un po' il codice a questi signori?
Se fino a ora siamo stati relativamenti sicuri con password da 8 caratteri alfanumerici, significa che poi dovremo immeterne 10, poi 12.
La complessità aumenta anche per noi.
Anche perchè per ogni account non si può sempre usare la stessa (se te ne inculano una, sei fregato).
Basta spostarsi nelle rete Wi-Fi, e vediamo come già ora sia possibile dal mr. nessuno di turno attaccare non solo reti WEP, ma anche WAP, e in tempi relativamente brevi (se si injecta, qualche mezz'oretta). Dei limiti SSID e MAC neppure a parlarne.
Credo che il problema di preservare i dati vada quindi copiato oltre dal mondo virtuale a quello fisico. Vedi gli accessi su soluzionil biometriche (che però andrebbero notevolmente affinati in termini di sicurezza), e il chip Fritz (che però non sembra piacere molto).

WPA in tempi brevi? :confused:
Link prego, finché non vedo non credo :p
(ovviamente parlo di chiavi pseudocasuali degne di questo nome)

Per i film in alta definizione è ancora più facile, la maggior parte dei software di riproduzione la legge in chiaro... :rolleyes:
Per ora, quando attiveranno l'HDCP la gente userà le GPU :rolleyes:
(e gli utenti avranno speso un'ennesima volta i loro soldi per sistemi
di protezione inutili, intanto chi li inventa, come Microsoft, ci fa i soldoni
alla facciazza nostra e quella dei distributori di contenuti...)

Bah, un buon sistema non teme attacchi brute force: ad esempio al quarto o quinto
tentativo andato male introduce un ritardo di 1 secondo che raddoppia per
ogni ulteriore tentativo fallito fatto nella stessa giornata.
(dopo 14 tentativi servono 20 minuti, più di una 20ina di tentivi
"a caso" al giorno non si posson fare).

Se le banche non sono manco arrivate a questo allora farebbero bene
ad assumere dei veri esperti e non dei raccomandati.

Il cracker lavora offline sul file delle password, è ovvio che non lavora online altrimenti lo sgamano subito :sofico:

Se fino a ora siamo stati relativamenti sicuri con password da 8 caratteri alfanumerici, significa che poi dovremo immeterne 10, poi 12.
La complessità aumenta anche per noi.


Di nuovo. Allora le password NON sono in discussione. Da remoto di poter
mandare 200'000 passwords al secondo te lo sogni, in locale idem
(soprattutto là dove servono i privilegi di amministratore per poter fare
il backup della RAM).

Resta scoperto il WPA, col problemino che comunque serve una signora GPU
per fare 200'000 combinazioni al secondo. Le attuali chiavi sono
a 128 bit, servono cioe' 2^128/200'000 =1,07 *10^33 secondi,
che in soldoni sono 5*10^25 anni, hai voglia a far diventare più veloci le GPU...

quello a cui può servire questo metodo è decrittare i files, in particolare là dove
si possano avere alcune informazioni sui files che ne devono uscire fuori
(riducendo così di gran lunga la casistica)

ma se si codificano stringhe con sha1 non è impossibile risalire alla stringa originaria???

( cmq quel video che hanno postato nella shell si legge il sito dell'uni di napoli.. però non mi sono soffermato ad ascoltare, che stanno facnedo? )

Sha1 è una funzione di hashing, quindi non invertibile, però se le provi tutte (attacco di forza bruta) puoi vedere se il risultato matcha con il digest crittato.

Il cracker lavora offline sul file delle password, è ovvio che non lavora online altrimenti lo sgamano subito :sofico:
Se le password non sono da dizionario ed il file è fatto bene, come cavolo
fa il cracker ad accorgersi di aver trovato le password giuste?

Nuova parola d'ordineUNIX : pippo
PAROLA D'ORDINE ERRATA: E' troppo breve
Nuova parola d'ordineUNIX : paperino
PAROLA D'ORDINE ERRATA: Si basa su un termine di dizionario


adf5gtk è tanto diversa da thjr7gf ? Mi sai dire quale delle due è la mia password?
O c'e' un algoritmo magico che le riconosce, magari venduto da Wanna Marchi & co.???

Tra l'altro come fa il cracker ad avere il file delle password se lo si può leggere solo
coi privilegi di root (e root non ha bisogno di password quando usa "su"... ) ???!?

Questi ragionamenti andavano bene 15 anni fa....

crackare il wpa in tempi brevi si può, i tool usati sono gli stessi per il cracking wep (la suite aircrak-ng, generalmente)
l'unica differenza è che devi basarti sul bruteforce/dictionary, percui password adeguatamente complesse (16+) sono ancora sicure

Se le password non sono da dizionario ed il file è fatto bene, come cavolo
fa il cracker ad accorgersi di aver trovato le password giuste?
adf5gtk è tanto diversa da thjr7gf ? Mi sai dire quale delle due è la mia password?
O c'e' un algoritmo magico che le riconosce, magari venduto da Wanna Marchi & co.???

Gli algoritmi sono pubblici, basta sapere quale viene utilizzato e provare tutte le chiavi finchè non matchano i risultati


Tra l'altro come fa il cracker ad avere il file delle password se lo si può leggere solo
coi privilegi di root (e root non ha bisogno di password quando usa "su"... ) ???!?


Ovviamente deve procurarsi il file delle password in qualche modo.


Questi ragionamenti andavano bene 15 anni fa....

:mbe:

Che tra l'altro in Unix le password sono crittate con una versione moddata del DES che è del '77.

Gli algoritmi sono pubblici, basta sapere quale viene utilizzato e provare tutte le chiavi finchè non matchano i risultati
Matchano con cosa? Se le passwords sono ghtr4klu e kjut5h con che cosa
matchano, con l'alfabeto latino?

Ovviamente deve procurarsi il file delle password in qualche modo.

L'unico modo è essere root. Ma se sei root non hai già più bisogno di alcuna
password, switch-user ("su") ti permette di accedere come qualsiasi utente
senza dover mettere la password.

Che tra l'altro in Unix le password sono crittate con una versione moddata del DES che è del '77.
Certo, ed i calcolatori sono binari come i mainframes originali degli
anni '40-50, e allora, che diavolo c'entra?
Ad esempio Pam viene aggiornato minimo un paio di volte l'anno,
il file delle password è cambiato dal '90 ad oggi,
(non è più /etc/passwd) etc.etc..

Matchano con cosa? Se le passwords sono ghtr4klu e kjut5h con che cosa
matchano, con l'alfabeto latino?

Il matching lo fai tra l'infiormazione presente nel file delle password e l'output dell'algoritmo che stai applicando (ovviamente devi sapere di che algoritmo si tratta, ma essendo pubblici è il problema minore) standotene offline per verificare se la password tentata è corretta.


L'unico modo è essere root. Ma se sei root non hai già più bisogno di alcuna
password, switch-user ("su") ti permette di accedere come qualsiasi utente
senza dover mettere la password.


Ma figurati, esisteranno centinaia di metodi per recuperare il file delle password. Ad esempio in Unix è pubblico.


Certo, ed i calcolatori sono binari come i mainframes originali degli
anni '40-50, e allora, che diavolo c'entra?

Non capisco dove vuoi arrivare. Io ho solo affermato che Unix per crittare le password usa il DES, leggermente modifcato (adesso non sto a spiegare come) che è del 77, negami questa affermazione se sei in grafo.

A proposito di sha1

http://boinc.iaik.tugraz.at/

Il matching lo fai tra l'infiormazione presente nel file delle password e l'output dell'algoritmo che stai applicando (ovviamente devi sapere di che algoritmo si tratta, ma essendo pubblici è il problema minore) standotene offline per verificare se la password tentata è corretta.

Di nuovo. Come cavolo verifichi che la password sia corretta se sei offline?
Come fai a fare matching se ci sono molteplici algoritmi, o molteplici
risultati che un singolo algoritmo può produrre? Mica si usano più algoritmi
fissi con crittatura fissa, e se sono algoritmi biunivochi col cavolo che fai
il matching da offline....

Ma figurati, esisteranno centinaia di metodi per recuperare il file delle password. Ad esempio in Unix è pubblico.

Certo, quando l'amministratore VUOLE che tu ottenga il detto file o quando
è talmente imbranato da non conoscere il significato di:

chown root:root filename
chmod 660 filename

In un qualsiasi sistema decorosamente amministrato il file delle password
non è accessibile al primo script-kiddie imberbe che passa di lì.
(e non mi parlare di anticaglia che girava sui 286, parliamo dei sistemi moderni adesso!!!)

Non capisco dove vuoi arrivare. Io ho solo affermato che Unix per crittare le password usa il DES, leggermente modifcato (adesso non sto a spiegare come) che è del 77, negami questa affermazione se sei in grafo.
? Non capisco dove vuoi arrivare tu, continuo a dire che fai ragionamenti da
script-kiddie oppure da hacker in pensione, o anche da cinefilo che si è
guardato svariate volte "Wargames". Ti dico che questi sistemi andavano
bene nel 1990, da allora le cose si sono evolute, e tu mi rispondi parlando
dello Unix originale, quello di SCO, che è ormai un sistema completamente
morto, defunto, desueto da decenni.....
Gli altri sistemi a cui fai riferimento quali sono, minix e BeOs? AmigaOs?
Poi mi verrai a dire che li fai girare su AlphaDigital oppure Sparc, perchè
sono il futuro :rolleyes:

Di nuovo. Come cavolo verifichi che la password sia corretta se sei offline?
Come fai a fare matching se ci sono molteplici algoritmi, o molteplici
risultati che un singolo algoritmo può produrre?

Provando tutte le chiavi forse? E vedendo se quello che ottieni matcha con quello che c'è nel file delle password. Ti faccio inoltre presente che a discapito del suo nome o file delle password non conitene le password. Un sistema NON ha bisogno e NON deve contenere le password degli utenti.


Mica si usano più algoritmi
fissi con crittatura fissa, e se sono algoritmi biunivochi col cavolo che fai
il matching da offline....

Per algoritmi "biunivoci" cosa intendi? Algoritmi di cifratura asimmetrici od algoritmi non invertibili, tipo i codici di hashing?


Certo, quando l'amministratore VUOLE che tu ottenga il detto file o quando
è talmente imbranato da non conoscere il significato di:

chown root:root filename
chmod 660 filename


Sinceramente non so come faccia uno ad appropriarsi del file delle password, perchè non l'ho studiato, ma suppongo che come per ogni cosa ci siano dei trucchetti più o menu astuti, probabilmente non sarà un'operazione facile, ma se presupponi in partenza che sia impossibile sbagli. Alla fine l'importante non è proteggere le password, ma assicurarsi che gli algoritmi di cifratura utilizzati siano efficaci, ovvero che ci voglia un tempo improponibile per crackarli. Se devi implementare un sistema di sicurezza, e la tua implementazione si basa unicamente sul tenere al sicuro il file delle password, sbagli in partenza.


In un qualsiasi sistema decorosamente amministrato il file delle password
non è accessibile al primo script-kiddie imberbe che passa di lì.
(e non mi parlare di anticaglia che girava sui 286, parliamo dei sistemi moderni adesso!!!)

? Non capisco dove vuoi arrivare tu, continuo a dire che fai ragionamenti da
script-kiddie oppure da hacker in pensione, o anche da cinefilo che si è
guardato svariate volte "Wargames". Ti dico che questi sistemi andavano
bene nel 1990, da allora le cose si sono evolute, e tu mi rispondi parlando
dello Unix originale, quello di SCO, che è ormai un sistema completamente
morto, defunto, desueto da decenni.....
Gli altri sistemi a cui fai riferimento quali sono, minix e BeOs? AmigaOs?
Poi mi verrai a dire che li fai girare su AlphaDigital oppure Sparc, perchè
sono il futuro :rolleyes:

Sarà, ma da quello che mi hai scritto prima tu invece mi dai l'impressione di uno che non sa nemmeno cosa sia la crittografia...

EDIT: Ci aggiungo anche che hai ragione nel dire che un sistema moderno protetto con misure di sicurezza moderne sia difficcile da bucare, però quando si lavora nel campo della sicurezza bisogna essere un pò paranoici, e prendere in considerazione anche il quasi impossibile. Ti faccio un semplice esempio. Sai perchè si è smesso di utilizzare SHA1 e si è passati ad MD5? Perchè è stata scoperta una collisione, una singola inutile collisione, però nel dubbio meglio passare a qualcosa di più robusto, come appunto SHA1.

@sommojames:
Forse inizio a comprendere di cosa parli, intendi dire che faresti il matching
verificando l'hash, ma in questo modo ottieni un dizionario, non una password,
ed il tuo dizionario non è neanche piccolo: come minimo migliaia di termini,
in genere di più.

E di nuovo anche se riduci le possibilità ti scontri contro le barriere:
un sistema serio non ti dà più di una ventina di tentativi al giorno ed avverte
l'amministratore dopo che ne hai falliti un certo tot di fila.

Resta quindi il fatto che, a meno che tu non conosca a priori una delle
password lì presenti (ma a quel punto l'accesso ce lo hai già), non hai modo
di avere accesso al sistema in meno di una decina di anni.

@sommojames:
Forse inizio a comprendere di cosa parli, intendi dire che faresti il matching
verificando l'hash, ma in questo modo ottieni un dizionario, non una password,
ed il tuo dizionario non è neanche piccolo: come minimo migliaia di termini,
in genere di più.

Mi spiego meglio. Hai un file delle password. Prendiamo UNIX ad esempio che lo conosco. La password scelta dall'utente viene usata come chiave di cifratura del DES per cifrare una sequenza di 64 zeri. Il risultato di questa operazione è salvato nel file delle password.
Adesso supponiamo che tu sia un cracker che si è appropriato del file delle password. Che fai? Ti prendi la tua sequenza di zeri ed inizi a provare tutte le permutazioni su 8 caratteri (in UNIX le pass sono tutte di 8 caratteri). Ovviamente non lo fai a mano, altrimenti diventi vecchio, hai un software che lo fa al posto tuo. Ad ogni esecuzione dell'algortimo verifichi se il risultato della tua cifratura matcha con quello che hai inserito come chiave, se matcha BINGO hai indovinato la password. Ovviamente un buon sistema deve fare in modo che il BINGO non arrivi dopo 5 secondi ma dopo anni.

PS In realtà UNIX non è proprio così, ho semplificato volutamente per fare l'esempio, ha dei salt specifici per ogni utente che modificano il comportamento delle sand box del DES.

E di nuovo anche se riduci le possibilità ti scontri contro le barriere:
un sistema serio non ti dà più di una ventina di tentativi al giorno ed avverte
l'amministratore dopo che ne hai falliti un certo tot di fila.

Verissimo, da qui la necessità di lavorare offline, altrimenti se il sistema di sicurezza è serio di sgama in mezzo secondo.


Resta quindi il fatto che, a meno che tu non conosca a priori una delle
password lì presenti (ma a quel punto l'accesso ce lo hai già), non hai modo
di avere accesso al sistema in meno di una decina di anni.

E' prorpio quello che dovrebbe fare un buon sistema di sicurezza ;)

questa cosa mi era venuta in mente di farla anni fà, ma sinceramente con una rivatnt 2 era un pò inutile farla ^^'

passoword di centinaia di caratteri ( quando li posso mettere ), quanto tempo ci vuole, un biliardo di anni :D ?

Mi spiego meglio. Hai un file delle password. Prendiamo UNIX ad esempio che lo conosco. La password scelta dall'utente viene usata come chiave di cifratura del DES per cifrare una sequenza di 64 zeri. Il risultato di questa operazione è salvato nel file delle password.
Adesso supponiamo che tu sia un cracker che si è appropriato del file delle password. Che fai? Ti prendi la tua sequenza di zeri ed inizi a provare tutte le permutazioni su 8 caratteri (in UNIX le pass sono tutte di 8 caratteri). Ovviamente non lo fai a mano, altrimenti diventi vecchio, hai un software che lo fa al posto tuo. Ad ogni esecuzione dell'algortimo verifichi se il risultato della tua cifratura matcha con quello che hai inserito come chiave, se matcha BINGO hai indovinato la password. Ovviamente un buon sistema deve fare in modo che il BINGO non arrivi dopo 5 secondi ma dopo anni.

PS In realtà UNIX non è proprio così, ho semplificato volutamente per fare l'esempio, ha dei salt specifici per ogni utente che modificano il comportamento delle sand box del DES.

Eccoci, proprio qui sta il punto, tu conosci gli algoritmi ma in teoria
i salt non ti sono conosciuti. Ora supponendo che tu non conosca i salt
e che essi siano un paio di caratteri generati attraverso una formula
speciale (mettiamo un numero di 3 cifre che sta nei files di configurazione,
che,di nuovo, devono essere leggibili solo dall'amministratore)
e messi (o tolti) in un paio di punti dentro le passwords prima
che queste siano date in pasto all'algoritmo.
A questo punto tu non conosci più l'algoritmo,o almeno: puoi sempre
fare un semplice brute forcing con MD5 e SHA1 ma se non conosci
questa nuova variabile e come rimuoverla con le passwords che trovi ti
ci puoi pulire.....

Verissimo, da qui la necessità di lavorare offline, altrimenti se il sistema di sicurezza è serio di sgama in mezzo secondo.

Ma lavorare "offline" nella vera crittatura, cioè quella dove l'algoritmo lo devi ricostruire e non
è noto a priori (cioè non la semplice funzione crittografica hash, ma crittografia vera e propria...),
è impossibile......
Puoi ad esempio ricostruire i messaggi e l'algoritmo quando hai parte del contenuto
(in tempo di guerra ad esempio per ricostruire gli algoritmi del nemico sapevano
che c'erano spazi ricorrenti, vocali frequenti, e spesso parole di 2-3 caratteri.
servivano comunque centinaia di messaggi per poter capire come funzionava un
dato algoritmo)

E' prorpio quello che dovrebbe fare un buon sistema di sicurezza ;)
Hum, credo che un sistema di sicurezza ottimo differenzi l'algoritmo in almeno una decina di modi
diversi e con un seme piuttosto bastardo (tipo "i primi 10 caratteri validi e non spazi
di /lib/security/pam_access.so"), per generare qualche migliaio di combinazioni che non siano
identificabili con brute-force.

In questo modo se anche tu avessi 2 accounts e 2 passwords già conosciute nel sistema,
non hai comunque alcuna speranza di fare breccia con uno stupido brute-force, almeno non offline....

passoword di centinaia di caratteri ( quando li posso mettere ), quanto tempo ci vuole, un biliardo di anni :D ?

In effetti se calcoli le possibili permutazioni su n caratteri n lo metti all'esponente quindi pasa molto, però chi caXXo se li ricorda 100 caratteri? :asd:

passoword di centinaia di caratteri ( quando li posso mettere ), quanto tempo ci vuole, un biliardo di anni :D ?
Dipende dall'algoritmo, ma c'e' un tetto massimo.
Supponendo che tu abbia 64 possibilità per ogni carattere (alfabeto
minuscolo e maiuscolo, cifre e qualche carattere speciale) si tratta
di 6 bits per carattere.

Se ad esempio la codifica è SHA1 e quindi a 160 bits, il massimo è 27 caratteri.

Tu puoi inserirne anche 100 ma chi te la cracca coi metodi
di sommojames (supponendo che non ci sia alcun salt a proteggertela)
troverà una password di 27 caratteri o meno che è equivalente alla tua
(in pratica gli basta dare quella per entrare nel tuo account).

Chip Fritz

@DevilsAdvocate

Crackarlo mi sembra un po' dura come operazione, dato che il tpm dovrebbe usare una crittografia asimmetrica e il token privato non dovrebbe essere accessibile (le specifiche del consorzio parlano di antitampering, poi se qualcuno riuscirà a smontare un chip, accedere al contenuto della memoria non volatile e interpretarne la struttura, specialmente quando si arriverà ai massimi livelli di integrazione con la scheda madre e la cpu, è tutto da vedere...).

Certo, finchè sarà possibile accedere a porzioni di dati in chiaro, e confrontarle con l'equivalente cifrato, un bruteforce potrà "bastare", ma i problemi veri nasceranno quando tutti i componenti (MB, cpu, vga, hd, chip audio, ecc.) si scambieranno i dati solo in forma criptata, non sarà certo facile... (magari, per i contenuti multimediali qualcosa si potrebbe riuscire a fare, qualora ci si apsettasse che, noto il formato, da qualche parte si trovino dei dati noti - descrittori del file, sottotitoli, ecc. - con un confronto basato su bruteforce, ma sta a vedere in quanto tempo...).

@MiKeLezZ

Per i motivi che dicevo prima, usare un tpm per criptare dati sensibili equivale a subordinarne la leggibilità alla "sopravvivenza" del chip stesso: ti si frigge la scheda madre -> puoi buttare l'hd...

In realtà, potresti usare ciascuna chiave per criptare anche un file generico, che conservi a parte in chiaro, così, eventualmente, si potrebbe tentare un confronto bruteforce per risalire alla chiave privata (da usare con un software, perchè il tpm non ti consentirà di inserire delle chiavi non generate al volo da se stesso, dopo la creazione in fabbrica - li si possono inserire le endorsement keys), ma a queste condizioni, vale la pena di usare un tpm? io credo che sarebbe mille volte meglio un chip di crittografia che ti consenta, con le prerogative dell'owner della macchina, di inserire le chiavi che vuoi e di ottenerne una copia, da conservare su apposita scheda di memoria in luogo sicuro: dal punto di vista dell'utente, questo sarebbe il vero "trusted computing". Non lo sarebbe, però, dal punto di vista di chi vuole usarlo come drm hardware...


Discorso di sommojames

(@ DevilsAdvocate)

Provo ad interpretarlo (ma credo che a questo punto sia già abbastanza chiaro). Si parte dal presupposto di essere già in possesso del benedettissimo file delle password e di poterlo analizzare per i caxxicelli propri... Si suppone anche di conoscere l'algoritmo di criptazione usato e il formato di questo file e l'algoritmo con cui viene generato (perchè comunque, i vari accorgimenti che uso per renderlo difficile da interpretare - salt "casuali", nella posizione e nella lunghezza, crittografati o meno; password/hash spezzate e mischiate, ecc. - non possono essere proprio casuali, dato che in qualche modo, quando, come sistema operativo, vado a usare quei dati per riscontrare la correttezza di una password, devo poter ottenere gli stessi identici risultati per una stessa password, cioè il file dev'essere comunque interpretabile). Bene: a questo punto mi "basta" riprodurre tutte le possibili combinazioni di caratteri valide come password, applicare l'algoritmo di crittografia opportuno, applicare l'algoritmo che mi consente di interpretare il password file e fare un confronto (cioè, alla fine sto solo crackando un file).

Naturalmente, potrebbero esserci diverse opzioni possibili per l'algoritmo di cifratura, come per la scrittura del file, ma il numero delle possibilità si restringerebbe rispetto al dover provare online tutte le pwd possibili, e comunque da qualche parte queste informazioni devono essere memorizzate, quindi, se ammettiamo che il pwd file è ottenibile in qualche modo, allora dobbiamo supporre che anche queste informazioni siano recuperabili: di conseguenza, proteggere le informazioni sulle password è importante, ma lo è ancora di più fare in modo che, una volta ottenute, il tempo necessario a scoprire una password sia inaccettabile.

Per quanto riguarda l'ottenimento di privilegi di root: ricordo di aver letto che le tecnologie di virtualizzazione hardware introdotte da intel e amd potrebbero consentire, in qualche modo, di creare un rootkit che faccia girare il sistema operativo del sistema host come una istanza virtualizzata, senza che questo possa accorgersene in alcun modo (vi sarebbe anche la possibilità di alterare le informazioni sul tempo di esecuzione di determiate istruzioni), potendo quindi tracciare (e alterare) tutte le operazioni dell'host e accedere ai dati in memoria...

Edit: doppio, scusate.

Eccoci, proprio qui sta il punto, tu conosci gli algoritmi ma in teoria
i salt non ti sono conosciuti. Ora supponendo che tu non conosca i salt
e che essi siano un paio di caratteri generati attraverso una formula
speciale (mettiamo un numero di 3 cifre che sta nei files di configurazione,
che,di nuovo, devono essere leggibili solo dall'amministratore)
e messi (o tolti) in un paio di punti dentro le passwords prima
che queste siano date in pasto all'algoritmo.
Sinceramente non mi ricordo come siano generati i salt, cmq non sono messi dentro la password, sono un ulteriore input per il DES che modifica il comportamento delle sand box. Adesso se vuoi sapere come funzionano le salt box ti consiglio una rapida ricerca su wiki, qualcosa dovrebbe saltare fuori. Cmq alla fine sono semplicemente un ulteriore input del DES, che quindi dilata esponenzialmente i tempi di recupero della pass. Ovvero per ogni chiave che provi (ossia la password stessa) devi provare un salt diverso.


A questo punto tu non conosci più l'algoritmo,o almeno: puoi sempre
fare un semplice brute forcing con MD5 e SHA1 ma se non conosci
questa nuova variabile e come rimuoverla con le passwords che trovi ti
ci puoi pulire.....
Come dicevo prima l'algoritmo lo conosci eccome, solo che aumentando il numero di input aumenti il numero di tentativi necessari per sgamare la pass. Anzi, ci aggiungo pure che i migliori algoritmi sono proprio quelli pubblici e ben noti. Se ad esempio provi ad elaborarti un algoritmo per conto tuo in totale segretezza e poi lo applichi, e la sua sicurezza si basa proprio sul fatto che l'algoritmo non è noto, commetti un grave errore, perchè tanto prima o poi diventarà noto (sul sistema ci metteranno le mani diverse persone). Al contrario gli algoritmi pubblici (nel senso di pubblicamente noti) sono universalmente ritenuti i più efficaci proprio perchè i matematici e gli esperti di crittografia di mezzo mondo li hanno analizzati e ne hanno valuto gli eventuali limiti.

Quando parli di MD5 e SHA1 non ti seguo, quello sono codici hashing (ovvero funzioni matematiche non invertibili e che non generano collisioni), non sono tecniche di brute forcing, vengono più che altro usati per autenticare messaggi, ovvero mando il messaggio A (magari anche in chiaro) con il digest K prodotto da SHA1 e col cazzo che il furbone si scrive un messaggio B diverso dal mio producendo il medesimo codice K, appunto perchè SHA-1 non genera collisoni.


Ma lavorare "offline" nella vera crittatura, cioè quella dove l'algoritmo lo devi ricostruire e non
è noto a priori, è impossibile......

Come dicevo prima l'algoritmo lo conosci eccome, visto che è pubblico.


Hum, credo che un sistema di sicurezza ottimo differenzi l'algoritmo in almeno una decina di modi
diversi e con un seme piuttosto bastardo (tipo "i primi 10 caratteri non spazi di /etc/fstab"),
per generare qualche migliaio di combinazioni che non siano identificabili con brute-force.

Non servirebbe a nulla questo, tanto si presuppone che l'utente malizioso conosca già il risultato della cifratura, e debba risalire alla stringa che l'ha generato. Metti ad esempio che si impossessi del file delle password, o ancora più semplicemente che intercetti il traffico nella rete (internet per definizione è ritenuta insicura).
O forse intendevi applicare algoritmi in cifratura in cascata? Quello è utilizzato ad esempio dal triple-DES, ovvero fai 3 DES in cascata (devi farne almeno 3, con 2 è intile perchè basta incrociare i dati ed il costo computazionale per forzarlo non aumenta), oppure ancora un cifrario a blocchi. Cmq si tratta di una tecniche abbastanza superate, anche se ancora molto usate, IMHO meglio un bel RSA che ci metti milioni di anni a forzarlo pure con le GTX in SLI :sofico:


In questo modo se anche tu avessi 2 accounts e 2 passwords già conosciute nel sistema,
non hai alcuna speranza di fare breccia con uno stupido brute-force, almeno non offline....
Giustissimo, non aggiungo altro.

Dipende dall'algoritmo, ma c'e' un tetto massimo.
Supponendo che tu abbia 64 possibilità per ogni carattere (alfabeto
minuscolo e maiuscolo, cifre e qualche carattere speciale) si tratta
di 6 bits per carattere.

La codifica più usata è la ASCII (si legge asky), ed ha 7 bit (l'ottavo è il bit di parità) e codifichi 128 caratteri. Adesso se vuoi calcolarti tutte le possibili permutazioni di 128 possibili caratteri su una password di (ad esempio) 8 caratteri fai 128^8 =~ 72*10^15 Si parla dunque di miliardi di miliardi di possibili permutazioni.


Se ad esempio la codifica è SHA1 e quindi a 160 bits, il massimo è 27 caratteri.

Tu puoi inserirne anche 100 ma chi te la cracca coi metodi
di sommojames (supponendo che non ci sia alcun salt a proteggertela)
troverà una password di 27 caratteri o meno che è equivalente alla tua
(in pratica gli basta dare quella per entrare nel tuo account).

No, perchè SHA1 non genera collisioni (almeno per ora nessuna ne ha trovata una), puoi anche mettergli un testo di 1 milione di caratteri e ti sparerà fuori sempre un risultato diverso. Qualora dovesse smettere di farlo, SHA1 cesserà di essere usato. Cmq il numero di possibili valori che sputa fuori.

PS Se siete interessati a sapere come funzia lo SHA1 c'è l'RFC 3174 a riguardo http://www.faqs.org/rfcs/rfc3174.html.

Chip Fritz

@DevilsAdvocate

Crackarlo mi sembra un po' dura come operazione, dato che il tpm dovrebbe usare una crittografia asimmetrica e il token privato non dovrebbe essere accessibile (le specifiche del consorzio parlano di antitampering, poi se qualcuno riuscirà a smontare un chip, accedere al contenuto della memoria non volatile e interpretarne la struttura, specialmente quando si arriverà ai massimi livelli di integrazione con la scheda madre e la cpu, è tutto da vedere...).


Non ti preoccupare vedi che con un piede di porco lo apriamo il Fritz, al massimo un pò di sano tritolo :sofico:

Discorso di sommojames

(@ DevilsAdvocate)

Provo ad interpretarlo (ma credo che a questo punto sia già abbastanza chiaro). Si parte dal presupposto di essere già in possesso del benedettissimo file delle password e di poterlo analizzare per i caxxicelli propri... Si suppone anche di conoscere l'algoritmo di criptazione usato e il formato di questo file e l'algoritmo con cui viene generato (perchè comunque, i vari accorgimenti che uso per renderlo difficile da interpretare - salt "casuali", nella posizione e nella lunghezza, crittografati o meno; password/hash spezzate e mischiate, ecc. - non possono essere proprio casuali, dato che in qualche modo, quando, come sistema operativo, vado a usare quei dati per riscontrare la correttezza di una password, devo poter ottenere gli stessi identici risultati per una stessa password, cioè il file dev'essere comunque interpretabile). Bene: a questo punto mi "basta" riprodurre tutte le possibili combinazioni di caratteri valide come password, applicare l'algoritmo di crittografia opportuno, applicare l'algoritmo che mi consente di interpretare il password file e fare un confronto (cioè, alla fine sto solo crackando un file).

Naturalmente, potrebbero esserci diverse opzioni possibili per l'algoritmo di cifratura, come per la scrittura del file, ma il numero delle possibilità si restringerebbe rispetto al dover provare online tutte le pwd possibili, e comunque da qualche parte queste informazioni devono essere memorizzate, quindi, se ammettiamo che il pwd file è ottenibile in qualche modo, allora dobbiamo supporre che anche queste informazioni siano recuperabili: di conseguenza, proteggere le informazioni sulle password è importante, ma lo è ancora di più fare in modo che, una volta ottenute, il tempo necessario a scoprire una password sia inaccettabile.

Vedo che sei arrivato all'essenza del mio discoso. Il messaggio che lancia un buon sistema di sicurezza (dico sistema e non algoritmo perchè gli algo possono essere più di uno) è il seguente, detto proprio in modo grezzo "rubami pure il file delle password, faccia pure una radiografia al mio sistema che tanto le password non le avari mai!".


Per quanto riguarda l'ottenimento di privilegi di root: ricordo di aver letto che le tecnologie di virtualizzazione hardware introdotte da intel e amd potrebbero consentire, in qualche modo, di creare un rootkit che faccia girare il sistema operativo del sistema host come una istanza virtualizzata, senza che questo possa accorgersene in alcun modo (vi sarebbe anche la possibilità di alterare le informazioni sul tempo di esecuzione di determiate istruzioni), potendo quindi tracciare (e alterare) tutte le operazioni dell'host e accedere ai dati in memoria...

Ecco, ad esempio già tu hai ipotizzato un possibile metodo per ottenere i provilegi di root. E' difficilmente attuabile, non alla portata di tutti, ma cmq chi pianifica la sicurezza di un sistema lo deve tenere cmq presente, visto che le contromisure da attuare sono decisamente poco costose da attuare rispetto a quanto costerebbe non attuarle affatto.

crackare il wpa in tempi brevi si può, i tool usati sono gli stessi per il cracking wep (la suite aircrak-ng, generalmente)
l'unica differenza è che devi basarti sul bruteforce/dictionary, percui password adeguatamente complesse (16+) sono ancora sicure
Io parlavo di chiavi pseudocasuali adeguatamente complesse (tipo quelli degli AP alice per farti un esempio).

La codifica più usata è la ASCII (si legge asky), ed ha 7 bit (l'ottavo è il bit di parità) e codifichi 128 caratteri. Adesso se vuoi calcolarti tutte le possibili permutazioni di 128 possibili caratteri su una password di (ad esempio) 8 caratteri fai 128^8 =~ 72*10^15 Si parla dunque di miliardi di miliardi di possibili permutazioni.



No, perchè SHA1 non genera collisioni (almeno per ora nessuna ne ha trovata una), puoi anche mettergli un testo di 1 milione di caratteri e ti sparerà fuori sempre un risultato diverso. Qualora dovesse smettere di farlo, SHA1 cesserà di essere usato. Cmq il numero di possibili valori che sputa fuori.

PS Se siete interessati a sapere come funzia lo SHA1 c'è l'RFC 3174 a riguardo http://www.faqs.org/rfcs/rfc3174.html.

Continui a parlare come uno che ha imparato a memoria la teoria e basta....
Che diavolo ce ne frega se nessuno finora ha trovato collisioni? Finora non
potevan fare brute-force con 200'000 tentativi al secondo....

Una chiave SHA1 è 160 bits FISSI cioè offre 2^160 combinazioni.
Una password a 27 caratteri su 6 bits ciascuno offre 2^162 combinazioni,
cioè 4 volte tante. Quindi DI MEDIA ad ogni chiave corrispondono
4 passwords differenti da 27 caratteri.
Una password a 100 caratteri sono 2^600 combinazioni, per ogni chiave
ci saranno circa 2^440 passwords differenti che la generano.
(2^540 se parti da 128 simboli differenti)

Se codifichi 128 simboli diversi stai su 7 bits e questo succede
se superi i 160 / 7 = 23 digits. Con tutto questo studio della
crittografia Hash è strano che nessuno ti abbia spiegato cosa è la
ridondanza dei dati o altri concetti di matematica di base
(la vera crittografia è tutta matematica)...

Diventa quindi ovvio che andando oltre i 27 caratteri dovranno
esistere molteplici passwords che diano la stessa chiave (il tuo algoritmo
non fa i miracoli, 2 +2 da 4 .).
Questo perchè le funzioni hash hanno un dominio teoricamente infinito (i numeri naturali)
ma un codominio finito (i numeri naturali rappresentabili su 160 bits per SHA1 ,
256 o 512 bits per SHA2 , etc.etc.)

Continui a parlare come uno che ha imparato a memoria la teoria e basta....
Tu mi dai invece l'impressione di uno che la teoria manco la conosce, visto che quello che mi dicevi ieri sul crackare il file dell pwd :asd:


Che diavolo ce ne frega se nessuno finora ha trovato collisioni? Finora non
potevan fare brute-force con 200'000 tentativi al secondo....

Le funzioni di hashing vengono utilizzate per autenticare messaggi, sfruttando il fatto che non generano collisioni, se una funzione di hashing inizia a generare collisioni e' inutile. Per cifrare password le funzioni di hashing non sono molto adatte, meglio usare qualcosa di piu' robusto tipo un DES-CBC.

EDIT: il fatto che a te non te ne freghi niente non mi riguarda, io posto quel che mi pare, e ti inviterei ad essere piu' educato in seguito.


Una chiave SHA1 è 160 bits FISSI cioè offre 2^160 combinazioni.
Una password a 27 caratteri su 6 bits ciascuno offre 2^162 combinazioni,
cioè 4 volte tante. Quindi DI MEDIA ad ogni chiave corrispondono
4 passwords differenti da 27 caratteri.
Una password a 100 caratteri sono 2^600 combinazioni, per ogni chiave
ci saranno circa 2^440 passwords differenti che la generano.

Infatti mi sono sbagliato prima a parlare di testi di milioni di caratteri, SHA1 e' scritto in modo da cifrare sempre e solo blocchi di 128 bit, quindi il problema non sussiste. Se sei curioso di sapere come funziona nel dettaglio il funzionamento nell'RFC che ho linkato prima.


(la vera crittografia è tutta matematica)...

Veramente sono laureato... Cmq non sapevo esistesse una falsa crittografia :asd:

Si suppone anche di conoscere l'algoritmo di criptazione usato e il formato di questo file e l'algoritmo con cui viene generato (perchè comunque, i vari accorgimenti che uso per renderlo difficile da interpretare - salt "casuali", nella posizione e nella lunghezza, crittografati o meno; password/hash spezzate e mischiate, ecc. - non possono essere proprio casuali, dato che in qualche modo, quando, come sistema operativo, vado a usare quei dati per riscontrare la correttezza di una password, devo poter ottenere gli stessi identici risultati per una stessa password, cioè il file dev'essere comunque interpretabile).
Si, ma come fa l'hackerozzo di turno a sapere da dove vengono i semi dei
salt casuali se ho la facoltà di inserirli in un altro file "privato" che non sia
quello delle passwords (e di cui non gli vado a dire il nome)?
Si fa un backup del mio sistema completo?

Quello che continua a mancarvi è che un conto sono i libri di testo ed un
altro conto sono le applicazioni pratiche. Sui libri di testo l'algoritmo
di crittatura è puramente MD5 o SHA1, invece basta pochissimo, basta
poter fare affidamento su funzioni di crittatura elementari e su un semplice
seme di 5 caratteri "non memorizzato come /etc/pass/seme.txt" per far
si che gli scriptini dei vari cogl***azzi a giro possano servire solo come
carta igenica. Ed i sistemi di sicurezza seri (banche, etc.etc.) usano ben di
più che questi basilari algoritmi di crittatura biunivoci
(dominio=codominio), il nostro script kiddie potrebbe stare anni a cercare
di capire come diavolo codificano le passwords.

Già che ci siamo ci metto anche un esempio stupidissimo di algoritmo,
diciamo che dal seme (5 caratteri) si può estrarre un numero N a 8 cifre
decimali e uno a singola cifra P.
In base a P si decide come applicare N alla prima password,
l'operazione più semplice è la somma (per ogni digit si somma la cifra
corrispondente e poi si fa il modulo), poi la sottrazione, poi variazioni delle
stesse (sommi un digit sottrai il successivo). Ogni password dopo la prima presenta
una variazione diversa dovuta sia ad N che a P.
Adesso PRIMA che sia applicato MD5 o SHA, la password è cambiata, e ci sono
almeno 100'000 variazioni possibili grazie al seme. Se anche l'hacker arrivasse
a conoscere l'algoritmo, senza il seme non se ne fa di nulla.

E per conoscere dove sta il seme deve andare a disassemblare il programma
che effettua il login , ma se ne fosse in grado non gli servirebbero affatto le passwords
(gli basterebbe cracckare il detto programma).
Inoltre, di nuovo, se l'hacker potesse avere i privilegi di root prima di cercare le
passwords, non avrebbe già più bisogno di cercarle.

Si, ma come fa l'hackerozzo di turno a sapere da dove vengono i semi dei
salt casuali se ho la facoltà di inserirli in un altro file "privato" che non sia
quello delle passwords (e di cui non gli vado a dire il nome)?
Si fa un backup del mio sistema completo?


Semplicemente li prova tutti, manco la password la sa, anche quelle le deve provare tutte, e' tanto difficile da capire?


Quello che continua a mancarvi è che un conto sono i libri di testo ed un
altro conto sono le applicazioni pratiche. Sui libri di testo l'algoritmo
di crittatura è puramente MD5 o SHA1, invece basta pochissimo, basta
poter fare affidamento su funzioni di crittatura elementari e su un semplice
seme di 5 caratteri "non memorizzato come /etc/pass/seme.txt" per far
si che gli scriptini dei vari cogl***azzi a giro possano servire solo come
carta igenica. Ed i sistemi di sicurezza seri (banche, etc.etc.) usano ben di
più che questi basilari algoritmi di crittatura biunivoci
(dominio=codominio), il nostro script kiddie potrebbe stare anni a cercare
di capire come diavolo codificano le passwords.
Illuminaci tu allora che sarai responsabile della sicurezza alla San Paolo :asd:
Cmq continui a partire dal presupposto sbagliato, ovvero che il cracker non conosca l'lagoritmo. Che ne sai che non lavora li? Che ne sai che non e' stato lui stesso a scegliere l'alogortimo usato per cifrare la password? Quando lavori nel settore della sicurezza devi essere paranoico per definizione, devi dare per scontato anche il quasi impossibile, o cmq il poco probabile.
A sto punto se dovessimo dare retta a quel che dici tu tanto vale tenere le password in chiaro in un file che e' leggibile solo da root, magari verificare soltanto che non siano contenute in un dizionario (anche le possibili varianti per essere sicuri, es pippo1 ecc..) et voila' e' fatto il sistema di sicurezza. Non basta.


Cmq ti ripeto che SHA1 viene usato per autenticare ;)

Semplicemente li prova tutti, manco la password la sa, anche quelle le deve provare tutte, e' tanto difficile da capire?

ASD, e li matcha con il pi**no di Remì? Non ha modo di matcharli offline
con niente, deve andare per tentativi sulla macchina originale. punto. stop.

Adesso PRIMA che sia applicato MD5 o SHA, la password è cambiata, e ci sono
almeno 100'000 variazioni possibili grazie al seme. Se anche l'hacker arrivasse
a conoscere l'algoritmo, senza il seme non se ne fa di nulla.


Se conosci una banca che cifra le password con SHA1 dimmi quel'e' che andiamo tutti a fare il prevlievo :sofico:
Cmq seriamente, quando dico che l'algoritmo e' pubblico, non dico che fanno un serivizio al telegiornale e magari ci faccio anche il volantinaggio in giro :rotfl:

Vuol semplicemente dire che la sicurezza non si basa su quello, il sistema deve essere sicuro anche se l'algoritmo e' conosciuto del dettaglio (prendi sempre ad esempio che chi vuol forzare le pass sia lo stesso che ha implementato lo stesso sistema). Ti faccio un esempio. Uno dei miei professori di sicurezza all'uni era il responsabile della sicurezza al San Paolo, ovviamente non e' che mi viene a raccontare nel dettaglio dei loro sistemi si sicurezza (non c'e' ragione di semplificare la vita ad un eventaule utente malizioso ;)), cmq quei sistemi, qulunque essi siano, sono studiati per essere sicuri ed impenetrabili anche se sono conosciuti nel dettaglio.

Cmq continui a partire dal presupposto sbagliato, ovvero che il cracker non conosca l'lagoritmo. Che ne sai che non lavora li? Che ne sai che non e' stato lui stesso a scegliere l'alogortimo usato per cifrare la password? Quando lavori nel settore della sicurezza devi essere paranoico per definizione, devi dare per scontato anche il quasi impossibile, o cmq il poco probabile.
Di nuovo, se l'hacker è l'amministratore gli basta dare

su sommojames
e senza alcuna password entra e ti pulisce il conto. Per questo chi occupa queste
cariche viene pagato bene e controllato parecchio. Devi almeno supporre che chi
ha tirato su la baracca non ti voglia fregare, altrimenti non serve la crittazione
neanche se accendi un cero ci scampi...

ASD, e li matcha con il pi**no di Remì? Non ha modo di matcharli offline
con niente, deve andare per tentativi sulla macchina originale. punto. stop.

Vabbe', qua facciamo passi indietro. Ti ricordo che il cracker lavora offline con il file delle password, quindi il matching lo fa con quello che c'e' scritto nel file delle password. punto. stop.
Se non hai il file delle password cosa cracki, l'aria?

Di nuovo, se l'hacker è l'amministratore gli basta dare

su sommojames
e senza alcuna password entra e ti pulisce il conto. Per questo chi occupa queste
cariche viene pagato bene e controllato parecchio. Devi almeno supporre che chi
ha tirato su la baracca non ti voglia fregare, altrimenti non serve la crittazione
neanche se accendi un cero ci scampi...

L'amministratore cerca le pecche del proprio sistema, ovvio che non si mette a fare "su", la password di root la conosce, ed e' anche ovvio che i test li fa offline! In quanto il sistema e' replicato e non si puo' permettere di andare a toccare il sistema online.

Di nuovo, se l'hacker è l'amministratore gli basta dare

su sommojames
e senza alcuna password entra e ti pulisce il conto. Per questo chi occupa queste
cariche viene pagato bene e controllato parecchio. [b]Devi almeno supporre che chi
ha tirato su la baracca non ti voglia fregare[b], altrimenti non serve la crittazione
neanche se accendi un cero ci scampi...


Se le password sono protette come dio comanda manco l'amministratore le cracka ;)

cmq quei sistemi, qulunque essi siano, sono studiati per essere sicuri ed impenetrabili anche se sono conosciuti nel dettaglio.
Ma io è da questo che sono partito, dal fatto che i sistemi in giro non
sono affatto in pericolo, da qui è emerso:

-Nei sistemi privati non puoi fare cracking "offline" perchè non hai modo di accedere al file delle passwords, se non hai già compromesso il sistema.

-Nei sistemi pubblici (dove un qualche firbetto potrebbe provare a tenersi il
file delle passwords) confermi pure tu che non c'e' verso di entrare, io mi
accontentavo di un seme casuale e tu parli di algoritmi molto più forti,
fine del problema.

-Da remoto o da locale il brute-force con 200'000 combinazioni al secondo
te lo sogni, non lo puoi usare.

(-è emerso anche che non sapevi quale fosse il risvolto matematico di
avere una chiave a 160 bits fissi, ma lasciamo stare, si vede il tuo prof.
si è preoccupato di più di raccontarti gli aneddoti sulle banche)

Allora risiamo al punto di partenza, che diavolo ci fai con tutta sta forza
bruta se non decodificare i files?

Se le password sono protette come dio comanda manco l'amministratore le cracka ;)
L'amministratore ha sempre la possibilità (e la responsabilità) di cambiarle.
A volte per impedire che questo "potere" sia nelle mani di uno solo possono
esserci sistemi multiamministratore, dove comandi dati al livello più alto
richiedono la conferma di due o più persone, o dove tutto quello che viene
fatto dall'account dell'amministratore viene loggato.
Ma resta il fatto che un amministratore NON ha neanche bisogno di
cracckare le passwords è lui che amministra il sistema.
(e su tutti i SO, avere il massimo livello di accesso informatizzato e fisico
al sistema significa poterci fare veramente di tutto)

L'amministratore ha sempre la possibilità (e la responsabilità) di cambiarle.
A volte per impedire che questo "potere" sia nelle mani di uno solo possono
esserci sistemi multiamministratore, dove comandi dati al livello più alto
richiedono la conferma di due o più persone, o dove tutto quello che viene
fatto dall'account dell'amministratore viene loggato.
Ma resta il fatto che un amministratore NON ha neanche bisogno di
cracckare le passwords è lui che amministra il sistema.
(e su tutti i SO, avere il massimo livello di accesso informatizzato e fisico
al sistema significa poterci fare veramente di tutto)

Guarda che l'amministratore non conosce la password, al massimo si mette lui a provare a crackare il file per verificare se ci sono password deboli, ma non le conosce e non ha bisogno di conoscerli.

Cmq prima ho detto una cosa inesatta, quando dicevo che i sistemi di sicurezza sono sicuri anche se pubblici, ma non vengono certo pubblicizzati piu' di tanto. In realta' e' vero l'opposto, vengono resi pubblici appositamente perche' gli utenti ne certifichino il livello di sicurezza e tendano dunque a fidarsi.

(-è emerso anche che non sapevi quale fosse il risvolto matematico di
avere una chiave a 160 bits fissi, ma lasciamo stare, si vede il tuo prof.
si è preoccupato di più di raccontarti gli aneddoti sulle banche)


Ho fatto un errore e non ho problemi ad ammetterlo (a differenza di te), non ricordavo come funzionasse lo SHA1, poi ho preso l'RFC e mi sono informato. Di certo l'errore non l'ho commesso per carenze matematiche, visto che son laureato e di corsi a carattere matematico ne ho fatti parecchi.

Adesso non mi metto certo a rinfacciarti i tuoi errori, non ne vedrei lo scopo, mi limito solo a ricordarti che parli tanto di attacchi a forza bruta ma non sapevi manco come avvenissero.

Guarda che l'amministratore non conosce la password, al massimo si mette lui a provare a crackare il file per verificare se ci sono password deboli, ma non le conosce e non ha bisogno di conoscerli.

Cmq prima ho detto una cosa inesatta, quando dicevo che i sistemi di sicurezza sono sicuri anche se pubblici, ma non vengono certo pubblicizzati piu' di tanto. In realta' e' vero l'opposto, vengono resi pubblici appositamente perche' gli utenti ne certifichino il livello di sicurezza e tendano dunque a fidarsi.

Allora, sei amministratore? Ecco svariati metodi per rubare l'identità
dei tuoi utenti senza usare alcun bruteforce nè conoscerne le passwords:

1) comando passwd <nomeutente> e glie la cambi. (brutale!)
2) comando su <nomeutente> o comando sudo <nomeutente>.
(Se non presenti nel sistema, ce li installi, visto che TU puoi cambiare
i files di configurazione, dai a su e sudo la possibilità di accedere senza
dover dare la password.)
3) backup del file password, riscrittura della password con la propria,
uso dell'identità e ripristino del file password originario
4) modifica delle impostazioni del server (autenticazione=no) durante un
periodo di offline,accesso,ripristino e rimessa online nel giro di 5 secondi
(una volta che sei dentro farai tutte le zozzerie che vuoi).

Ce ne sono parecchi altri, resta comunque il fatto che se hai accesso in
scrittura ai files di configurazione e di sistema, hai il potere totale su quel
sistema, sempre e comunque. Non ti metterai a fare computazioni brute force
perchè non ti serve ad un tubo.

Non mi parlare di libri di testo e del vecchio metodo DES del '77, se hai mai
avuto realmente i privilegi di amministratore su un sistema *nix allora
sai benissimo di cosa sto parlando e che ho ragione.
Se invece non è così, e non hai idea di che significhi essere root, puoi tornare
a giocare coll'Xbox, tanto che si possano craccare le password o meno a te non ti tocca...

Adesso non mi metto certo a rinfacciarti i tuoi errori, non ne vedrei lo scopo, mi limito solo a ricordarti che parli tanto di attacchi a forza bruta ma non sapevi manco come avvenissero.

Ehm, ti parlavo di funzioni biunivoche ed a quelle siamo tornati,
funzioni che partono da una password generica e generano una password generica.
(ed il matching non lo fai copiando le funzioni che trovi sui libri di testo per bimbi pacioccosi)

Affermavo che il brute force lo usi come carta igenica e tu stesso lo hai
confermato, a meno che tu non sia l'amministratore il brute force non
lo usi. Peccato che l'amministratore non ne ha alcun bisogno :rolleyes: .

Ho detto una cosa sulle password a 100 caratteri, hai avuto la presunzione di
correggermi senza nemmeno provare a leggere cosa scrivevo, e ci
hai fatto non solo una gran figuretta, ma hai dimostrato di non conoscere
la matematica di base, quella da cui partono tutti i concetti di crittografia.
(viene da domandarsi se gli algoritmi di crittografia li hai studiati ad un
corso per la patente europea....).

Hai parlato di algoritmi teorici "piatti" (plain) e ci hai messo 80 giri di
parole a tirar fuori i salts, ma siccome il tuo prof non te li ha spiegati ed il
tuo libro non ne parla, hai detto "facciamo che i salts non ci siano".
Peccato che i salts (così come altri metodi ed algoritmi basati su seme) ci
sono, ed è inconfutabile.

Confondi continuamente la crittografia con la generazione di chiavi
attraverso funzioni hash crittografiche (e invece sono due cose diverse
quanto il giorno e la notte).

Adesso dimmi pure quali errori ho fatto io, sono tutto orecchie.

Non mi parlare di libri di testo e del vecchio metodo DES del '77, se hai mai
avuto realmente i privilegi di amministratore su un sistema *nix allora
sai benissimo di cosa sto parlando e che ho ragione.


Scusa, ma tu quanti algoritmi di crittografia conosci ed hai implementato per dirmi che il DES e' roba da preistoria? Conosci il DES CBC? Anni luce avanti rispetto a quel trucchetto dei semi di cui mi parlavi.
Cmq tu di che sistema sei amministratore? Stando a sentire te tanto vale memorizzare le password in chiaro, tanto il file delle password e' protetto ed e' impossibile che qualcuno a parte l'amministratore possa leggerlo, vero? Dimmi anche solo un motivo per sbattersi a cifrare le password se tanto il file delle password non esiste neanche la minima possibilita' che un utente malintenzionato se ne appropri.

Se invece non è così, e non hai idea di che significhi essere root, puoi tornare
a giocare coll'Xbox, tanto che si possano craccare le password o meno a te non ti tocca...

Seguiro' il tuo consiglio ed ordinero' una xbox...

Cmq da come imposti i tuoi discorsi mi sembri uno di quei smanettoni di Linux che si fanno i "fighi" perche' conoscono a menadito centinia di comandi ma poi non ti sanno manco distinguere tra un algoritmo a complessita' polinomiale da uno esponenziale :doh:

Confondi continuamente la crittografia con la generazione di chiavi
attraverso funzioni hash crittografiche.


Mi sta venendo il dubbio che tu sappia cosa sia un funzione di hash...
Cmq non sono stato io a tirare fuori il discorso dello SHA-1, ne tantomeno di utilizzarlo per cifrare le password :asd: SHA-1 e' invece utilizzato, lo ripeto per l'n-esima volta, per autenticare.

Hai parlato di algoritmi teorici "piatti" (plain) e ci hai messo 80 giri di
parole a tirar fuori i salts.

Si, in effetti non sono aggiornato sugli algoritmi moderni :asd:, magari vuoi aggiornarmi tu?
Sentriamo, se dovessi proteggere le password di una banca, che algoritmo usi?

EDIT: guarda che il seme non e' altro che un input non noto, provi ad indovinare anche quelle facendo tutte le combinazioni. Ovviamente il numero dei tentativi aumenta, cmq sebbene il sistema di pretezione delle password di Unix sia retenuto ancora affidabile ci sono ovviamente sistemi ben piu' solidi (vedi AES, erede del DES, DES CBC, algoritmi a chiave pubblica).

EDIT: guarda che il seme non e' altro che un input non noto, provi ad indovinare anche quelle facendo tutte le combinazioni. Ovviamente il numero dei tentativi aumenta, cmq sebbene il sistema di pretezione delle password di Unix sia retenuto ancora affidabile ci sono ovviamente sistemi ben piu' solidi (vedi AES, erede del DES, DES CBC, algoritmi a chiave pubblica).

Di nuovo, quelli sono algoritmi hash per chiavi, non algoritmi di crittografia.
Tu puoi fare le combinazioni perchè questi algoritmi te lo permettono, hai il risultato
che devi ottenere e l'algoritmo che lo genera.
Hai qualcosa con cui fare il matching. (sai che devi ottenere quel risultato
su 160 bits e sai l'algoritmo, andando a ripetere questa operazione più volte risali
anche al seme usato).
Se però usi anche il seme (un'altro, non il solito) con una funzione che ti trasformi
jkh5gth in ju7sliw, entrambe passwords valide, funzione biunivoca con dominio pari
al codominio, NON puoi fare matching con niente (nada, nix).
Ottieni una combinazione VALIDA per ogni possibile seme.
Se l'algoritmo è fatto bene, anche se tu conoscessi 1 password del sistema
"a priori" ridurresti le possibilità di un fattore 10 e non di più.
Ora ci metti un seme a 10 caratteri su 64 simboli ed hai ad
esempio 2^60 combinazioni. Toglici pure un fattore 10, anzi facciamo un
fattore 1000 (2^10) perchè conosci ben 3 passwords (cambiare password allo
stesso utente ovviamente non comporta alcun guadagno, quindi devono
essere le passwords di 3 utenti diversi).

Hai come risultato 2^50 combinazioni da provare una ad una e solo
"online" da remoto o in locale, perchè NON puoi fare alcun matching,
questo NON è un algoritmo per generare chiavi ma un algoritmo
INVERTIBILE, BIUNIVOCO, di crittografia VERA.(e nelle passwords non
puoi presumere che ci siano spazi ricorrenti, vocali frequenti, articoli
o preposizioni come facevano invece nella seconda guerra mondiale,
non hai termini da dizionario e quindi NON ci sono appigli)


NOTA: La funzione è invertibile se conosci il seme. Ma se non lo conosci,
esistono svariate migliaia di semi che possono portare da una
password originaria alla sua versione codificata, e per di più un altro utente non avrebbe
ottenuto lo stesso risultato,quindi non è tanto facile risalire al seme.

Di nuovo, quelli sono algoritmi hash per chiavi, non algoritmi di crittografia.
:rotfl: Oddio cosa mi tocca sentire. Adesso il DES e l'AES sono degli algoritmi di hashing :rotfl: Assumo come scusante che tu non sappia come sia un hashing.

Tu puoi fare le combinazioni perchè questi algoritmi te lo permettono, hai il risultato
che devi ottenere e l'algoritmo che lo genera.
Hai qualcosa con cui fare il matching. (sai che devi ottenere quel risultato
su 160 bits e sai l'algoritmo, andando a ripetere questa operazione più volte risali
anche al seme usato).
Se però usi anche il seme (un'altro, non il solito) con una funzione che ti trasformi
jkh5gth in ju7sliw, entrambe passwords valide, funzione biunivoca con dominio pari
al codominio, NON puoi fare matching con niente (nada, nix).
Ottieni una combinazione VALIDA per ogni possibile seme.
Se l'algoritmo è fatto bene, anche se tu conoscessi 1 password del sistema
"a priori" ridurresti le possibilità di un fattore 10 e non di più.
Ora ci metti un seme a 10 caratteri su 64 simboli ed hai ad
esempio 2^60 combinazioni. Toglici pure un fattore 10, anzi facciamo un
fattore 1000 (2^10) perchè conosci ben 3 passwords (cambiare password allo
stesso utente ovviamente non comporta alcun guadagno, quindi devono
essere le passwords di 3 utenti diversi).

Hai come risultato 2^50 combinazioni da provare una ad una e solo
"online" da remoto o in locale, perchè NON puoi fare alcun matching,
questo NON è un algoritmo per generare chiavi ma un algoritmo
INVERTIBILE, BIUNIVOCO, di crittografia VERA.(e nelle passwords non
puoi presumere che ci siano spazi ricorrenti, vocali frequenti, articoli
o preposizioni come facevano invece nella seconda guerra mondiale,
non hai termini da dizionario e quindi NON ci sono appigli)


NOTA: La funzione è invertibile se conosci il seme. Ma se non lo conosci,
esistono svariate migliaia di semi che possono portare da una
password originaria alla sua versione codificata, e per di più un altro utente non avrebbe
ottenuto lo stesso risultato,quindi non è tanto facile risalire al seme.

Questo invce te lo quoto perchè è corretto (a parte qualche insinuazione ma si può tranquillamente sorvolare ;)), così troviamo un punto di incontro, finalmente :cincin:
Cmq tieni presente che una volta che conosci il "seme" (che sta memorizzato da qualche parte) l'algoritmo diventa maggiormente vulnerabile. Esistono algoritmi molto più sicuri di quello che hai descritto (anche se in realtà non mi hai descritto un algoritmo specifico ma solamente una caratteristica generale), che continuano ad essere sicuri anche se l'utente malintenzionato conosce tutte le informazioni memorizzate nel sistema, e che pertanto sono preferibili.

EDIT: Cmq quando dici "questo NON è un algoritmo per generare chiavi ma un algoritmo
INVERTIBILE, BIUNIVOCO, di crittografia VERA" a che algoritmo ti riferisci? E' un algoritmo noto o l'hai inventato te? Come funziona al suo interno? Che permutazioni fa? Come lo implementeresti tu?

Dunque, a parte l'ennesimo brevetto, a parte il brute force....

La notizia mi sembra abbastanza importante per una cosa: hanno sfruttato la GPU per qualcosa non inerente la grafica. Il che non mi pare proprio cosi' immediato. Pensandoci un attimo, la cosa potrebbe essere sfruttata anche per altre applicazioni.

Inoltre una domanda: ma se le GPU hanno un processo di elaborazione dati parallelo molto piu' potente delle CPU, perche' questo non viene sfruttato anche sulle CPU???

Wow, quante cavolate si vedono scritte: tutti a fare a chi ce l'ha più lungo, a chi ne sa di più, a chi conosce meglio la crittografia e le sue implementazioni. Cercherò di non entrare in questo turbine, ma un paio di precisazioni le voglio fare:
PIANTATELA DI FARE DISTINZIONE TRA ALGORTIMI CRITTOGRAFICI E HASH.
Scusate lo sfogo, ma un algoritmi di hashing è un particolare algoritmo crittografico, che vi piaccia o no; un qualsiasi libro di crittografia serio (e per serio intendo un libro usato da matematici) ve lo può confermare.
Un algoritmo di hashing ha per forza collisioni. Non si scappa: siccome cerca di codificare un numero infinito di parole con un numero finito di possibilità, necessariamente infinite parole avranno lo stesso hash. Il punto è quanto è facile trovare delle collisioni: anche una funzione che codifica qualsiasi cosa con l'hash "pippo" è tecnicamente un algoritmo di hashing, solo che è un po' deboluccio...
La legge d'oro della crittografia prevede che un algoritmo è buono se pur essendo note TUTTE le variabili (i dettagli dell'algoritmo, la password crittata, i salt ecc.) non si riesce a risalire in tempo utile al messaggio in chiaro; ovviamente è sempre bene cercare di rendere il più difficile possibile l'accesso a queste variabili. Il discorso non vale per l'algoritmo: quello deve essere noto. Mamma MS non ha seguito la legge d'oro per XP, ed uno studente dell'università di Napoli in un tempo ridicolo è riuscito a rompere l'algoritmo con cui il file SAM (quello dove sono conservati gli hash) viene crittato. Che io sappia, ci vuole comunque accesso ad un OS diverso sulla stessa macchina per recuperare il file SAM, ma potrei sbagliarmi. Come dicevo nel mio post precedente, poi, l'algoritmo di hashing usato in XP è penoso.
Come ha fatto notare qualcuno, la complessità di un attacco a forza bruta, aumenta esponenzialmente con l'aumentare della lunghezza delle password; pur volendo ammettere che la potenza dei pc raddoppi ogni anno, un fattore 25 corrisponde ad un salto in avanti di 13 anni. Un carattere in più allunga i tempi di cose come migliaia di anni, quindi per algoritmi fatti bene (e usati bene) 25 è una differenza trascurabile. Ovviamente per quelli fatti male, o che sono lì lì per diventare obsoleti il discorso cambia. Ammettiamo che per trovare una password di XP al momento occorra al massimo un mese (sto sparando a caso, ma non troppo), con questo nuovo sistema ci vorrà poco più di un giorno. Ecco dunque che le pwd di XP diventano inutili :-).

PS: Non resisto, voglio farlo anche io:
Comunque a quello che leggo, penso di poter affermare che i frequentatori di questo thread, di matematica ne sanno pochina...

Dunque, a parte l'ennesimo brevetto, a parte il brute force....

La notizia mi sembra abbastanza importante per una cosa: hanno sfruttato la GPU per qualcosa non inerente la grafica. Il che non mi pare proprio cosi' immediato. Pensandoci un attimo, la cosa potrebbe essere sfruttata anche per altre applicazioni.

Inoltre una domanda: ma se le GPU hanno un processo di elaborazione dati parallelo molto piu' potente delle CPU, perche' questo non viene sfruttato anche sulle CPU???

Infatti, non ci avrei scommesso un euro che si potesse fare. Però c'è anche da vedere che genere di algoritmi riesce a crackare. La news dice che si son passati dall'ordine dei mesi a quelli dei giorni, ma con che algoritmo? perchè forzare un cifrario di Cesare non mi sembra la stessa cosa di forzare un cifrario RSA...

Wow, quante cavolate si vedono scritte: tutti a fare a chi ce l'ha più lungo, a chi ne sa di più, a chi conosce meglio la crittografia e le sue implementazioni. Cercherò di non entrare in questo turbine, ma un paio di precisazioni le voglio fare:
PIANTATELA DI FARE DISTINZIONE TRA ALGORTIMI CRITTOGRAFICI E HASH.
Scusate lo sfogo, ma un algoritmi di hashing è un particolare algoritmo crittografico, che vi piaccia o no; un qualsiasi libro di crittografia serio (e per serio intendo un libro usato da matematici) ve lo può confermare.
Infatti la crittografia è solo una delle possibile applicazioni delle funzioni di hash. Puoi usarle ad esempio per implementare gli indici di un DBMS.


Un algoritmo di hashing ha per forza collisioni. Non si scappa: siccome cerca di codificare un numero infinito di parole con un numero finito di possibilità, necessariamente infinite parole avranno lo stesso hash. Il punto è quanto è facile trovare delle collisioni: anche una funzione che codifica qualsiasi cosa con l'hash "pippo" è tecnicamente un algoritmo di hashing, solo che è un po' deboluccio...
Bhe dai, non è matematicamente dimostrabile, alcune funzioni sono studiate appositamente per essere resistenti alle collisioni (forse immuni, chi lo sa). Prendi SHA-1 ad esempio, nessuno gli ha ancora sgamato 1 collisione.
L'algoritmo che hai detto fa il 100% di collisioni :sofico:


La legge d'oro della crittografia prevede che un algoritmo è buono se pur essendo note TUTTE le variabili (i dettagli dell'algoritmo, la password crittata, i salt ecc.) non si riesce a risalire in tempo utile al messaggio in chiaro; ovviamente è sempre bene cercare di rendere il più difficile possibile l'accesso a queste variabili. Il discorso non vale per l'algoritmo: quello deve essere noto.

Dannazione, ti straquoto, è quello che sto cercando di dire da almeno una decina di messaggi (:asd:). Un algoritmo non può definirsi sicuro se affida troppo alla segretezza dei metodi utilizzati.

Mamma MS non ha seguito la legge d'oro per XP, ed uno studente dell'università di Napoli in un tempo ridicolo è riuscito a rompere l'algoritmo con cui il file SAM CUT...

:asd: Ben gli sta :nonsifa:


Comunque a quello che leggo, penso di poter affermare che i frequentatori di questo thread, di matematica ne sanno pochina...
Scusa, in basa a cosa lo affermi, non sapevo che questo thread fosse diventato l'esame di analisi :asd:

@sommojames

Credo che la news stia semplicemente affermando che diminuendo i tempi di un fattore 25, se per craccare qualcosa (qualsiasi cosa) prima ci volevano mesi, adesso ci vogliono giorni. Naturalmente se prima ci volevano 25000 anni, adesso ce ne vogliono solo mille, ma la cosa non è un gran miglioramento :)

@sommojames

Credo che la news stia semplicemente affermando che diminuendo i tempi di un fattore 25, se per craccare qualcosa (qualsiasi cosa) prima ci volevano mesi, adesso ci vogliono giorni. Naturalmente se prima ci volevano 25000 anni, adesso ce ne vogliono solo mille, ma la cosa non è un gran miglioramento :)

Detta così ha un senso, grazie ;)

Infatti la crittografia è solo una delle possibile applicazioni delle funzioni di hash.
Ehm, io in effetti intendevo esattamente il contrario: un algoritmo di hashing è un particolare algoritmo crittografico, non stavo parlando di applicazioni. La crittografia è la materia che studia gli algoritmi crittografici. Poi ci sono le implementazioni. Ma in ogni caso dubito che ci sia una definizione assoluta di crittografia, in più forse sono un po' troppo OT, quindi direi che basta che ci capiamo...

Bhe dai, non è matematicamente dimostrabile

Sì che lo è, ed è anche facile :) . Comunque mi pare che qualche mese fa (direi intorno a febbraio-marzo) un (una?) cinese ha trovato delle collisioni in SHA-1, anche se l'ultima volta che sono andato a controllare il suo articolo era ancora solo in cinese :D .

Scusa, in basa a cosa lo affermi, non sapevo che questo thread fosse diventato l'esame di analisi

Sulla base di nulla, in effetti era solo per il brivido di trollare una volta nella vita :D. E per potermi vantare, una volta tanto, di essere laureato in matematica e di aver, anche se per un breve periodo, fatto ricerca in crittografia. :Prrr:
Ebbene sì, per una volta, una volta tanto CE L'HO PIU' LUNGO IO!
Muahahaha :sbonk:
Scusate, giuro che la smetto qui.
Tanto per tornare leggermente IT:
Inoltre una domanda: ma se le GPU hanno un processo di elaborazione dati parallelo molto piu' potente delle CPU, perche' questo non viene sfruttato anche sulle CPU???
Credo, ma potrei sbagliarmi, che sia perché le GPU raggiungano questo risultato grazie al fatto di essere estremamente specializzate, e questo rende più notevole il fatto di riuscire ad usarle per scopi "non convenzionali"

Ehm, io in effetti intendevo esattamente il contrario: un algoritmo di hashing è un particolare algoritmo crittografico, non stavo parlando di applicazioni. La crittografia è la materia che studia gli algoritmi crittografici. Poi ci sono le implementazioni. Ma in ogni caso dubito che ci sia una definizione assoluta di crittografia, in più forse sono un po' troppo OT, quindi direi che basta che ci capiamo...

Sono vere entrambe le affermazioni. L'hashing è un algoritmo per cifrare, ma non il solo (come dici), ma è altresì vero che l'hashing trova altre applicazioni oltre alla crittografia. Ad esempio molti DBMS commerciali consentono di usare le funzioni di hashing al posto dei B-alberi per implementare gli indici. Il principio è il seguente: il dato da inserire (solitamente la chiave relazionale, che è univoca) viene hashata ed il valore di hashing costituisce l'indirizzo logico dove memorizzare il dato. In questo modo in base al valore memorizzato si ottine a costo costante K l'accesso al dato stesso. Ovviamente deve generare poche collisioni, altrimenti si perde il vantaggio (i dati che collidono sono memorizzate in delle liste che vanno poi scandite).


Sì che lo è, ed è anche facile :) . Comunque mi pare che qualche mese fa (direi intorno a febbraio-marzo) un (una?) cinese ha trovato delle collisioni in SHA-1, anche se l'ultima volta che sono andato a controllare il suo articolo era ancora solo in cinese :D .

Non lo sapevo, chissà se adesso abbandoneranno SHA-1 come con MD5. Cmq alla fine se son solo poche collisioni direi che è ancora piuttosto sicuro IMHO.


Sulla base di nulla, in effetti era solo per il brivido di trollare una volta nella vita :D. E per potermi vantare, una volta tanto, di essere laureato in matematica e di aver, anche se per un breve periodo, fatto ricerca in crittografia. :Prrr:
Ebbene sì, per una volta, una volta tanto CE L'HO PIU' LUNGO IO!
Muahahaha :sbonk:
Scusate, giuro che la smetto qui.
Tanto per tornare leggermente IT:

Io invece son laureato in informatica, la mia preparazione ovviamente non sarà all'altezza di un laureato in matematica, cmq ho dato moltio esami di matematica. D'altra parte sono i stati i matematici ad inventare l'informatica, quindi un informatico deve essere anche un pò un matematico.

Credo, ma potrei sbagliarmi, che sia perché le GPU raggiungano questo risultato grazie al fatto di essere estremamente specializzate, e questo rende più notevole il fatto di riuscire ad usarle per scopi "non convenzionali"
*

Wow, quante cavolate si vedono scritte: tutti a fare a chi ce l'ha più lungo, a chi ne sa di più, a chi conosce meglio la crittografia e le sue implementazioni. Cercherò di non entrare in questo turbine, ma un paio di precisazioni le voglio fare:
PIANTATELA DI FARE DISTINZIONE TRA ALGORTIMI CRITTOGRAFICI E HASH.
Scusate lo sfogo, ma un algoritmi di hashing è un particolare algoritmo crittografico, che vi piaccia o no; un qualsiasi libro di crittografia serio (e per serio intendo un libro usato da matematici) ve lo può confermare.
Un algoritmo di hashing ha per forza collisioni. Non si scappa: siccome cerca di codificare un numero infinito di parole con un numero finito di possibilità, necessariamente infinite parole avranno lo stesso hash. Il punto è quanto è facile trovare delle collisioni: anche una funzione che codifica qualsiasi cosa con l'hash "pippo" è tecnicamente un algoritmo di hashing, solo che è un po' deboluccio...
La legge d'oro della crittografia prevede che un algoritmo è buono se pur essendo note TUTTE le variabili (i dettagli dell'algoritmo, la password crittata, i salt ecc.) non si riesce a risalire in tempo utile al messaggio in chiaro; ovviamente è sempre bene cercare di rendere il più difficile possibile l'accesso a queste variabili. Il discorso non vale per l'algoritmo: quello deve essere noto. Mamma MS non ha seguito la legge d'oro per XP, ed uno studente dell'università di Napoli in un tempo ridicolo è riuscito a rompere l'algoritmo con cui il file SAM (quello dove sono conservati gli hash) viene crittato. Che io sappia, ci vuole comunque accesso ad un OS diverso sulla stessa macchina per recuperare il file SAM, ma potrei sbagliarmi. Come dicevo nel mio post precedente, poi, l'algoritmo di hashing usato in XP è penoso.
Come ha fatto notare qualcuno, la complessità di un attacco a forza bruta, aumenta esponenzialmente con l'aumentare della lunghezza delle password; pur volendo ammettere che la potenza dei pc raddoppi ogni anno, un fattore 25 corrisponde ad un salto in avanti di 13 anni. Un carattere in più allunga i tempi di cose come migliaia di anni, quindi per algoritmi fatti bene (e usati bene) 25 è una differenza trascurabile. Ovviamente per quelli fatti male, o che sono lì lì per diventare obsoleti il discorso cambia. Ammettiamo che per trovare una password di XP al momento occorra al massimo un mese (sto sparando a caso, ma non troppo), con questo nuovo sistema ci vorrà poco più di un giorno. Ecco dunque che le pwd di XP diventano inutili :-).

PS: Non resisto, voglio farlo anche io:
Comunque a quello che leggo, penso di poter affermare che i frequentatori di questo thread, di matematica ne sanno pochina...

:sofico:

@DevilsAdvocate

Come fa un hackerozzo non lo so;
ma un hackerone forse può (:p)
quindi, per pararmi il posteriore, faccio tutto il possibile per complicargli la vita:

- rendo il più possibile inaccessibili le informazioni sulle password crittografate (presidio il pwd file)

- complico l'algoritmo di "ricostruzione" della password

- assumo che fallirò nei primi due compiti, quindi mi preoccupo di scegliere un algoritmo crittografico che farà venire i capelli bianchi al pronipote del pronipote dell'hacker(ozzo/one).

In un mondo ideale basterebbero i primi due accorgimenti, ma in quel mondo non ci sarebbero nè ladri, nè assassini, nè malintenzionati di nessun tipo, quindi non dovrei fare un bel niente. Nel mondo reale mi ricordo che un buon software deve resistere a una testata nucleare e mi rassegno a dover compiere anche il terzo sforzo, che è poi il decisivo (in quanto ultima difesa del forte). Del resto, da buon siciliano, come potrei trascurare la saggezza popolare? Ecco: un vecchio adagio dice (tradotto) "chi ti 'sa' ti apre" (visto che sono in vena, aggiungo anche questo: "prima cerca vicino, poi lontano" - l'oggetto della ricerca, chiaramente, è la causa dei tuoi mali). E io, sospettoso e zelante, mi preoccupo che qualcuno, prima o poi, "saprà". Così, di getto, mi vengono in mente due casi in cui la conoscenza di ciò che voglio celare con i primi due punti della strategia difensiva può essere ottenuta:

1) La talpa è un amministratore. Ma perchè non dovrebbe fare le semplici cosucce che suggerisci tu? La mia ipotesi è questa:

- il sistema è multiamministrato, ed architettato in modo che tutti gli amministratori, messi insieme, abbiano i pieni poteri di root, ma nessuno, preso singolarmente, li abbia (per cui certe operazioni vanno svolte parzialmente da ciascuno, altre vanno svolte con il consenso di tutti);

- le operazioni degli amministratori sono loggate, e nessuno da solo può accedere ai log e manipolarli;

- il su è possibile solo congiuntamente (ad esempio, tutti gli altri ne ricevono notifica sul proprio terminale di accesso e ognuno digita la propria password separatamente, dopo di che le operazioni di chi ha richiesto il su verranno monitorate);

- uno degli amministratori (guardacaso la nostra talpa), ha poteri di backup in lettura, ma non può sostituire certi file (file delle pwd, file col seme), nè modificare certe impostazioni (certe sue prerogative sui file, le impostazioni sul file del seme, ecc.), perchè i poteri di backup in scrittura (=sostituzione) sono affidati ad un altro amministratore, e comunque i suddetti file sono autenticati e sostituibili solo con una versione "originale" (toh, diciamo che ad ogni modifica - es: nuovo utente e nuova password aggiunti - il sistema in automatico appone una diversa firma, generata al volo, che consente di risalire alla versione del file, e calcola un hash, salvando la firma - associata alla data di creazione - e l'hash in file a parte che possono essere sostituiti solo da tutti gli amministratori congiuntamente: così posso permettermi di limitare a due - per paranoia, ma ne basta uno, se si vuole risparmiare uno stipendio cospicuo - il numero degli amministratori addetti al backup);

- ciascun amministratore ha una conoscenza completa dell'architettura di sicurezza (è inevitabile: la scelta degli algoritmi di manipolazione e crittografia delle password dev'essere chiaramente gestita e monitorata da tutti, per non dare ad uno solo il potere di fregare il sistema: potrebbe sostituire il meccanismo dei semi e dei salt con delle identità matematiche in modo che tutte le password producano lo stesso input all'algoritmo crittografico, quindi aggiungere un algoritmo biunivoco per modificare il risultato da memorizzare, per far apparire i risultati della crittografia come diversi senza che questo incida sulla possibilità di accedere con una qualsiasi password a qualsiasi account).

A questo punto la mia talpa si porta via una copia di backup del pwd file e del/i file con il/i seme/i (ma questo non serve, giusto? se conosco l'algoritmo, e abbiamo detto nell'ultimo punto che lo conosco, allora mi basta creare degli account per avere dei match e risalire a ciò che non so, ragion per cui non mi sono preoccupato di impedirgli l'accesso a questo file insieme a quello delle pwd) e la passa ad un complice (perchè se fa il lavoro da se a casa, visto che serve tempo, non vuole correre il rischio di essere scoperto). Il complice provvederà a craccare il file (ma se non vogliamo il complice, non importa, non lo mettiamo :p fa tutto la talpa :p) e recuperare le password con l'approccio bruteforce: ecco che la scelta di un algoritmo crittografico con le @lle quadrate rivela la sua utilità contro questo tipo di attacchi.


2) Dall'esterno, sfruttando un exploit di sicurezza (opportunamente scovato) si riesce ad avviare un rootkit (anche parziale), ma si verificano le seguenti condizioni:

- l'exploit consente di ottenere solo alcuni poteri (comunque utili)

- l'attacker sa (per esperienze pregresse, soffiate dall'interno, ecc.) che il sistema è controllato strettamente con sistemi di analisi delle prestazioni, rilevatori di rootkit, ecc. che non può aggirare del tutto; diciamo che, in un modo o nell'altro, può ottenere un breve lasso di tempo (ad esempio tra una scansione e l'altra) che non gli basta per fare tutto ciò che vorrebbe, ma solo per carpire il pwd file e il file seme, più le informazioni sui salti che gli servono (tu puoi chiamare i file come vuoi, ma il sistema operativo - o comunque il layer che si occuperà della gestione delle pwd - deve sapere cosa fare, quindi ci sarà un file di configurazione dove il nome è scritto, e in qualche file di configurazione saranno scritte le informazioni sull'algoritmo usato per alterare la password prima della crittografia, o almeno il nome del programma/script usato per la crittografia, quindi può copiarlo e disassemblarlo per capire come funziona - suppongo però che non possa cambiarlo con uno alterato, per via dei suoi poteri comunque limitati) e coprire le sue tracce (potrebbe fare il tutto a più riprese: entra, prende i file di configurazione ed esce prima di essere scoperto; stuida i file e capisce cosa andare a cercare; rientra, prende quello che gli serve e riesce).

A questo punto, avrebbe tutto l'occorrente per fare quello che tu comunque consideri possibile: craccare un file. E anche stavolta l'unica difesa possibile sarebbe fare in modo che la vecchiaia lo uccida prima di trovare un match (l'ideale sarebbe fare in modo che il match arrivi quando ormai è in fin di vita, così quando cerca di premere invio e lanciare l'attacco definitivo, per l'artrite e il parkinson preme del, il risultato viene cancellato e gli viene un collasso :Perfido: lo so, sono cattiiivoooooo).

@sommojames

Tornando al tpm: che ne dici se fondiamo l'associazione Amici del Piede di Porco (AdPdP)? Ho pronta anche la propagine internazionale: PdP forever e anche lo slogan:

Let's PdP together,
Let's fight the TPM!

:sofico:

@shutz

Se anche la sola definizione di crittografia fosse chiara, avremmo un buon punto di partenza per violarne gli algoritmi e dovremmo reinventarla (non è il concetto della security through obscurity, ma quello del "non voglio impazzire, fank@l@ la matematica, le banche, le rapine, e pure io!!!!" )

:sofico:

domanda:
ma se le probabilita' di trovare una password offline in qualsiasi modo non sono infinite (bene o male fatta la legge, trovato l'inganno), la cosa bella sarebbe iniziare ad avere 4 processor1 (vedi cell) in parallelo ed 8vga in sli (vedi 8800gtc@zz)...
la somma di tutte le componenti in quanto a capacita' computative e parlando di componenti che possono effettuare operazioni in parallelo sarebbe una semplice somma algebrica oppure una somma esponenziale?
mi inizierei a preoccupare se fossero esponenziali con qualsiasi algoritmo di protezione.
venendo al dunque sapendo che:
- le possibilita' di creare un seme NON SONO POSSIBILITA' INFINITE
- le possibilita' di creare un hash NON SONO POSSIBILITA' INFINITE
si ha che:
- le possibilita' di ricevere come out da un algoritmo di codifica sono MAGGIORI DI 0.
credo che con questo metto d'accordo (si scrive con l'apostrofo?) un po tutti, no???
resta sempre da vedere il tempo computazionale... pero' insomma si fanno cray di centinaia di processori... perche' non di vga...

Scusa, come fai a moltiplicare tra di loro le potenze dei singoli componenti? Al più le puoi sommare, se l'algoritmo ti consente di sfruttare tutto l'hardware (ma parlando di brute force diciamo che si può). Cioè, se devi fare mille prove e disponi di due processori, potrai fare due prove alla volta e, quindi, dimezzi il tempo (ogni processore farà 500 prove, quindi, lavorando in parallelo, nel tempo di farne 500 con uno le hai completate tutte e 1000); se aggiungi altri due processori, per un totale di 4, hai ridotto ad un quarto il tempo necessario, cioè hai una dipendenza lineare. Quanto alle gpu, considerale, per lo scopo, come un insieme di processori che lavorano allo stesso compito: diciamo che una gpu corrisponde a dieci processori single core, due corrisponderanno a venti, ma in definitiva ho solo raddoppiato linearmente la potenza iniziale (una gpu).

@sommojames

Tornando al tpm: che ne dici se fondiamo l'associazione Amici del Piede di Porco (AdPdP)? Ho pronta anche la propagine internazionale: PdP forever e anche lo slogan:

Let's PdP together,
Let's fight the TPM!

:sofico:

Io mi ci iscrivo subito :sofico:

domanda:
ma se le probabilita' di trovare una password offline in qualsiasi modo non sono infinite (bene o male fatta la legge, trovato l'inganno), la cosa bella sarebbe iniziare ad avere 4 processor1 (vedi cell) in parallelo ed 8vga in sli (vedi 8800gtc@zz)...
la somma di tutte le componenti in quanto a capacita' computative e parlando di componenti che possono effettuare operazioni in parallelo sarebbe una semplice somma algebrica oppure una somma esponenziale?
mi inizierei a preoccupare se fossero esponenziali con qualsiasi algoritmo di protezione.
venendo al dunque sapendo che:
- le possibilita' di creare un seme NON SONO POSSIBILITA' INFINITE
- le possibilita' di creare un hash NON SONO POSSIBILITA' INFINITE
si ha che:
- le possibilita' di ricevere come out da un algoritmo di codifica sono MAGGIORI DI 0.
credo che con questo metto d'accordo (si scrive con l'apostrofo?) un po tutti, no???
resta sempre da vedere il tempo computazionale... pero' insomma si fanno cray di centinaia di processori... perche' non di vga...
Se un processore/scheda video/cell elabora X, 2 processori/schede video/cell elaborano 2X, no?

Cmq conta che hash, semi & co. possono essere modificati, se sono cose importanti magari ogni settimana cambi...

Se un processore/scheda video/cell elabora X, 2 processori/schede video/cell elaborano 2X, no?

Cmq conta che hash, semi & co. possono essere modificati, se sono cose importanti magari ogni settimana cambi...

Oppure fai un one-time-password, con la password che cambia ogni volta che la usi, se sono proprio cose di estrema importanza.

oppure a sto punto ad ogni tot tempo (immagino delle sessioni di mesi con il termine riavviare) in automatico viene cambiato randomicamente l'hash e il carattere/posizione dei singoli semi, cmq nulla e' impossibile... prendo la delorian e...

... e vai a sbattere contro un palo, perchè io l'ho presa prima di te e l'ho piantato dove dovevi arrivare... :asd: :Prrr:

be con le potenze attuali delle sv sarebbe un peccato non sfruttarle...

per il discorso sicurezza il problema non si pone su un sitema ben progettato...come quello del tempo di attesa di 1 secondo e poi raddoppiato ad ogni errore...

NO, ti prego, non ricominciamo tutto da capo...

Tu devi comunque pensare che qualunque meccanismo di protezione adotterai verrà aggirato (vedi esempio dell'amministratore corrotto privo dei pieni poteri), quindi alla fine la tua unica vera difesa è un meccanismo di crittografia robusto (l'aumento nella potenza di calcolo produce una diminuzione lineare del tempo necessario alla decrittazione, mentre l'aumento dei bit nelle chiavi e la scelta di algoritmi resistenti ad attacchi diversi dal bruteforce fa crescere quel tempo in maniera esponenziale). Tutto il resto è bello, utile, intelligente, necessario, indispensabile, quello che vuoi, ma è comunque un'impalcatura (pensa alle mura di un castello) che, per quanto impenetrabile, deve reggersi su delle fondamenta stabili (altrimenti il castello crollerebbe), e queste fondamenta non sono nè le tecniche di alteranzione della password nè l'occultamento del file delle pwd e delle tecniche per ricostruire la password a partire dalle informazioni che contiene, ma la sicurezza dell'algoritmo usato per cifrare queste informazioni.

NO, ti prego, non ricominciamo tutto da capo...


:rotfl: :rotfl: :rotfl:

Ti quoto il resto, ovviamente ;)

Per il discorso GPU contro CPU, che ne pensate? Come mai l'architettura parallela delle GPU non viene adottata anche per le CPU, se e' davvero molto piu' potente? Dipende dal fatto che bisognerebbe cambiare tutta l'architettura software e hardware, oppure c'e' qualche ostacolo meno evidente? A parte il palo contro la delorian... :D

PS: ma capita anche a voi che il forum non segnali le nuove risposte ad un thread, nonostante uno sia iscritto con notifica immediata?

Provo ad essere breve: una gpu è un processore molto specializzato, progettato per compiti specifici, che si prestano molto bene ad una parallelizzazione massiccia, mentre una cpu è pensata per fare mediamente bene qualsiasi cosa. Di conseguenza una cpu è anche più facile da programmare, perchè otterrai subito buone prestazioni (in proporzione alla sua potenza) senza cercare un'ottimizzazione spinta; una gpu, invece, va programmata con tutti i punti e virgola, e renderà bene solo in alcuni contesti, mentre in altri verrà sfruttata poco, con la maggior parte delle sue unità di calcolo a rigirarsi i pollici, a meno di fare i salti mortali per ottimizzare tutto (investendo quindi tempo e denaro) e senza alcuna garanzia sul risultato (non tutti gli algoritmi sono parallelizzabili, oltre un certo limite, quindi alla fine, per sfruttare molte unità in parallelo dovrai trovare qualcos'altro da fare - vale anche per le cpu multicore: alla fine, in ambito desktop, il vantaggio principale si ha nel multitasking: più cose fai, più fluido va il pc). Oppure, può fare da coprocessore ad una cpu: la cpu organizza per bene il lavoro da fare (e ne svolge una parte), mentre la gpu-coprocessore lo svolge con rapidità, coniugando la flessibilità della prima alla potenza specializzata della seconda (ma alla fine, questa tecnica darà risultati eccellenti in ambiti tuttosommato ristretti). E' un discorso che vale, in generale, per tutti quei processori che hanno un elevato grado di specializzazione (quindi potresti aver letto commenti simili su cell in altri thread - anche miei :p).

Io alle notifiche ho rinunciato da un bel po' :boh:

Sono d'accordo con il tuo discorso. Comunque mi sono informato un pochino in giro e devo dire che ci sono ottime aspettative per il futuro. Lo sfruttamento delle GPU per compiti non specificatamente grafici ha addirittura un nome, GPGPU:

http://en.wikipedia.org/wiki/GPGPU

e qualcuno si lancia addirittura in previsioni di sfruttamento di tali tecnologie perl e cpu tradizionali:

http://www.theinquirer.net/en/inquirer/news/2007/04/03/gpgpu-vs-cpu-will-be-the-war-of-2008-9

Nell'articolo precisa che le GPU sono ottime per i calcoli matematici, ma non per gestire eventi random. Non vorrei dire una cavolata, ma credo faccia riferimento al sistema di interrupt e alla programmazione ad eventi. Se non ricordo male, se un programma richiede l'uso della CPU (ehi, e' il mio turno! :D) la CPU cacha i registri, esegue le operazioni richieste e continua a fare quello che stava facendo. Inoltre, se un evento esterno cambia la logica che deve seguire il calcolo dei dati, la CPU reagisce a questi cambiamenti. A quanto ho capito la GPU non e' fisicamente progettata per questo.

Pero'. Ora sparo un mio pensiero a casaccio, come e' mia abitudine.... e se si facesse un sistema di piccole GPU in parallelo gestite da una (o piu') CPU? Gli algoritmi verrebbero passati alle GPU, e la CPU centrale provvederebbe a comporre il flusso finale. Alla fin fine, anche le eccezioni dovute ad eventi random dovrebbero comunque seguire un algoritmo alternativo. In sostanza: GPU per fare calcoli, CPU per gestire le priorita', gli interrupt, le code ed i semafori e le eccezioni. Penso che alla fine i sistemi multiprocessore sfruttino un'idea analoga. O no?

(siate clementi :p)

Pero'. Ora sparo un mio pensiero a casaccio, come e' mia abitudine.... e se si facesse un sistema di piccole GPU in parallelo gestite da una (o piu') CPU? Gli algoritmi verrebbero passati alle GPU, e la CPU centrale provvederebbe a comporre il flusso finale. Alla fin fine, anche le eccezioni dovute ad eventi random dovrebbero comunque seguire un algoritmo alternativo. In sostanza: GPU per fare calcoli, CPU per gestire le priorita', gli interrupt, le code ed i semafori e le eccezioni. Penso che alla fine i sistemi multiprocessore sfruttino un'idea analoga. O no?

(siate clementi :p)Già fatto.
http://www.tgdaily.com/content/view/33657/135/
http://www.tgdaily.com/content/view/34688/118/

Già fatto.
http://www.tgdaily.com/content/view/33657/135/
http://www.tgdaily.com/content/view/34688/118/

Oh, mi copiano tutti........... :p

Sembra interessante e molto 'gnorante sta' cosa :D quando ci ho tempo ci do' una letta. Grazie Mikelezz :)

Una cpu tende ad essere più "reattiva" negli accessi alla memoria (grazie alla logica out-of-order, non resta ferma ad aspettare i dati, ma se può va avanti - però c'è da dire che le gpu hanno dei meccanismi per mascherare le latenze della memoria, visto che trattano dati sparsi, o random che dir si voglia, però sono meccanismi studiati per quel tipo di applicazione), e nei salti. Questo però non significa che una gpu non possa fare le stesse cose che fa una cpu: può farle praticamente tutte (a parte far partire un sistema operativo), però nella maggior parte dei casi la sua potenza di calcolo rimarrà sottosfruttata; poi c'è da dire che, in genere, le gpu elaborano dati in virgola mobile con una precisione di 16/32bit, quindi se devi operare sui double non va bene.

Il discorso che fai ha senso: si tratta di usare una cpu classica per gestire il lavoro, e svolgerlo in parte, e demandare i calcoli pesanti alla gpu, che fungerebbe da coprocessore. In un certo senso, è quasi un ritorno alle origini, quando la cpu conteneva solo l'alu e l'fpu era un'unità/coprocessore esterno (anche se attaccato nello stesso package); inoltre, nei supercomputer non è raro trovare cpu affiancate da coprocessori, che a volte sono proprio delle gpu adattate. Ultimamente è in voga l'idea di usare proprio delle schede video su pci-express come coprocessori: sia amd/ati, sia nvidia hanno presentato i loro progetti, con cpu affiancate da gpu in sli/crossfire; amd ha in progetto fusion, che prevede l'integrazione di cpu e gpu nello stesso package/die; infine, c'è il progetto terascale di intel, anch'esso interessante: usa molti piccoli core x86 "castrati" per elaborazioni in parallelo "massicce", con una notevole potenza di calcolo, ed è nato proprio per fare da coprocessore, ma alcuni rumor vorrebbero nei piani di intel anche l'uso di questo sistema per farne una vera gpu, per usi grafici. Insomma, nei prossimi anni ne vedremo delle belle.