Topic: [HackMe] Nuovo metodo più sicuro per storage di password  (Letto 543 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Ciao ragazzi, perdonate il titolo fantasioso e il fatto che questa discussione è stata già postata, ma sfortunatamente negli ambienti in cui l'ho fatto non mi è stato fornito un supporto adeguato.

Ho inventato un nuovo tipo di implementazione logica per lo storage delle password, invece della solita combinazione user/password.
Volevo dei consigli da voi, sia perchè lo possiate confutare e solo nel caso fosse effettivamente più sicuro, vorrei implementarlo nel kernel UNIX al posto di quello attuale (solo che non posso leggermi tutto il kernel, perciò se avete articoli utili per ciò che riguarda l'astrazione del login linkatemi pure per favore).

Cominciamo con una premessa: è ovvio che il server deve essere sicuro, l'implementazione è solo una soluzione aggiuntiva nel quale l'attaccante è riuscito a bypassare le misure precedenti: come lo può essere criptare una password, o disabilitare eventuali direttive, .

Ho creato un POC in MySQL/MariaDB, perchè secondo me rende bene il concetto ma si può ovviamente implementare anche in NoSQL, o addirittura modificando la struttura della gestione delle password in /etc/shadow utilizzando il nono campo come indice del file che contiene delle password randomiche, fra cui quella dell'utente (.

File .SQL (Ho semplificato il più possibile il codice per rendere il tutto il più comprensibile possibile: se non volete incorrere in concorrenze se effettuate un inserimento massivo di utenti deve essere applicato il LOCK)

Nella teoria se l'attaccante accede ai dati privati a volte si ritrova a dover decriptare la password dell'utente interessato (e ogni tanto lo fa come ultima spiaggia nel caso il server sia ben configurato e protetto), mentre così si ritrova con n passwords non sapendo quale è quella che deve decriptare.

Per esempio in sistemi amministrativi o login root potrebbero auto-generare nMila password hash "fake".

Ma rimando ad un altro utente che spiega benissimo il suo funzionamento:
MItaly
Citazione da: MItaly
Mm al di là del codice specifico, se ho ben capito la tua idea sarebbe non associare esplicitamente l'hash di salt+password all'utente, ma tenerli "alla rinfusa" in un'unica tabella, e usare il salt per evitare collisioni (oltre agli usuali problemi di sicurezza che risolve il salt).

Il miglioramento di sicurezza dovrebbe derivare dal fatto che, mancando l'associazione utente-password, dovrebbe essere più complesso cercare di craccare una password di un utente specifico, dato che non sai qual è l'hash corrispondente, ed è inoltre possibile aggiungere degli hash aggiuntivi "per depistaggio" alla tabella.

Confutazione del mio modello da parte di un utente:

Scara95

Citazione da: Scara95
Qualsiasi password restituisca uno degli hash presenti nella tua tabella hashes viene accettata, quindi invece di rendere il tutto più sicuro l'hai reso meno sicuro perché ci sono più possibilità fra cui scegliere

Non credo, hai letto il mio codice?

Contando che viene generate anche un salt (che possiamo, perchè no, rendere univoco), in questo caso non esisterà mai una combinazione salt+password che dia il risultato di un'altra chiave UNIVOCA della hash.

Mentre quanto è probabile la collisione di 255 chars di salt + [numero di stringhe che fanno da brute force per trovare una password qualsiasi], possa trovare una correlazione?

Googlando un pò ho anche trovato questo
Dove dice:

Citazione
A hash function accepts inputs of arbitrary (or at least very high)  length, and produces a fixed-length output. There are more possible  inputs than possible outputs, so collisions must exist. The whole point  of a secure hash function is that it is "collision resistant", which  means that while collisions must mathematically exist, it is very very  hard to actually compute one. Thus, there is no known collision for  SHA-256 and SHA-512, and the best known methods for computing one (by  doing it on purpose) are so ludicrously expensive that they  will not be applied soon (the whole US federal budget for a century  would buy only a ridiculously small part of the task).

Il rischio di questa collisione di cui parli, teoricamente, è attualmente, fortemente improbabile per non dire impossibile.

 Però siccome vogliamo fare le cose per bene, ipotizziamo di voler scongiurare l'improbabile:

Se io imponessi input di lunghezza fissa (password+salt = [sempre stesso numero di caratteri]) potrei prevenire la (im)probabilità matematica di collisione, se si, quale è questa lunghezza?

Grazie a chiunque dimostrerà interessamento.

=========================================================================================================

Si può chiudere.
Il metodo si può essere utile per non rilevare la password in chiaro (siccome bisognerebbe cercarla fra tante), però come una doppia lama fornisce nHash con cui cercare di collidere, quindi direi che il metodo è decisamente da buttare .

Ringrazio, minomic, Scara95 e MItaly ancora per il tempo speso, mi hanno permesso di evitare di buttare tempo in una implementazione seria dell'algoritmo.
« Ultima modifica: Ottobre 14, 2017, 19:33 da tommyb1992 »

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #1 il: Ottobre 15, 2017, 10:18 »
Sono un po' confuso...

Comunque...

> se avete articoli utili per ciò che riguarda l'astrazione del login linkatemi pure per favore

e' tutto sotto PAM. https://en.wikipedia.org/wiki/Linux_PAM

> Nella teoria se l'attaccante accede ai dati privati a volte si ritrova a dover decriptare la password dell'utente interessato

Mi verrebbe da dire "ma quando mai?" Cioe', se ha letto shadow, vuole dire che e' root. Quindi della password di qualcuno non se ne fa nulla: ha gia' tutto l'accesso di cui ha bisognoi/

Comunque sembra tu sia giunto alla conclusione che non sia una buona idea, e su questo sono d'accordo.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #2 il: Ottobre 16, 2017, 18:52 »
Mi verrebbe da dire "ma quando mai?" Cioe', se ha letto shadow, vuole dire che e' root. Quindi della password di qualcuno non se ne fa nulla: ha gia' tutto l'accesso di cui ha bisognoi/

Non sempre, sono stati presenti vulnerabilità che permettevano di leggere file anche senza gli adeguati permessi.
Per esempio: https://marco-pivetta.com/php-exploit-mysql-backdoor-with-load-data-local-infile/index.html

E poi il mio era un caso dei tanti nel quale avrei voluto applicarlo...

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #3 il: Ottobre 17, 2017, 09:07 »
Mi verrebbe da dire "ma quando mai?" Cioe', se ha letto shadow, vuole dire che e' root. Quindi della password di qualcuno non se ne fa nulla: ha gia' tutto l'accesso di cui ha bisognoi/

Non sempre, sono stati presenti vulnerabilità che permettevano di leggere file anche senza gli adeguati permessi.
Per esempio: https://marco-pivetta.com/php-exploit-mysql-backdoor-with-load-data-local-infile/index.html

No allora, pero' cerchiamo di capire quello che si sta dicendo. Non e' che MySQL ha improvvisamente permessi di fare quello che gli pare sul disco. E' un processo come tutti gli altri e segue le stesse regole. Onestamente non capisco nemmeno quale sia la sorpresa dell'articolo. MySQL ha una funzione per leggere un file. Se i permessi sono sufficienti a leggere quel file, lo potra' leggere. No shit?

Mi sembra un flashback negli anni 90. Cioe' davvero sta gente sta ancora facendo girare MySQL come root e poi si stupiscono se gli legge i files? E' una zona disagiata che non ha avuto connessioni ad internet negli ultimi 20 anni? O alternativamente... mettono suid su MySQL. Potrebbero anche creare un utente dentro wheel con username "abusami" e password "subito".

Offline Giornale di Sistema

  • python sapiens sapiens
  • ******
  • Post: 3.124
  • Punti reputazione: 4
    • Mostra profilo
    • Distillato di Python
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #4 il: Ottobre 17, 2017, 11:16 »
Potrebbero anche creare un utente dentro wheel con username "abusami" e password "subito".

 :D :D :D

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #5 il: Ottobre 17, 2017, 12:21 »
Mah, sì... nel mondo windows, dove chiunque crede che basta cliccare dieci volte a caso sullo schermo per trovare una "grave falla di sicurezza", report farlocchi come questo sono molto comuni. Raymond Chen sul suo blog ha raccolto un bel po' di aneddotica di questo tipo, sotto la categoria "It rather involved being on the other side of this airtight hatchway" (una citazione della guida galattica per autostoppisti, of course!).
Vale la pena di leggersi un po' di questi articoli, sono divertenti e istruttivi allo stesso tempo:
https://social.msdn.microsoft.com/search/en-US?rq=site%3Ablogs.msdn.microsoft.com%2Foldnewthing&rn=oldnewthing&ral=1&query=airtight+hatchway

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #6 il: Ottobre 17, 2017, 20:07 »
No allora, pero' cerchiamo di capire quello che si sta dicendo. Non e' che MySQL ha improvvisamente permessi di fare quello che gli pare sul disco. E' un processo come tutti gli altri e segue le stesse regole. Onestamente non capisco nemmeno quale sia la sorpresa dell'articolo. MySQL ha una funzione per leggere un file. Se i permessi sono sufficienti a leggere quel file, lo potra' leggere. No shit?

No a dir la verità ho cozzato totalmente io, con quel metodo non puoi leggere il file /etc/shadow, anche perchè non credo che MySQL/MariaDB sia eseguito come root (a meno che non lo imposti tu come tale, azione abbastanza stupida).

La vulnerabilità (o mancanza di professionalità/svista chiamatela come vi pare) era sfruttata in maniera differente, ovvero venivano letti i file che teoricamente non dovevano essere letti perchè veniva fatta una parziale configurazione di apache e php per impedire l'accesso ma non veniva fatto lo stesso con le funzioni mysql.

Come dice anche qua:
Citazione
The problem is that MySQL is a service running on it’s own. Usually, your PHP process is “jailed” within the limits of the www-data user or the one that suPHP has provided you…

Quindi se avevi un hosting semplice:

/var/www/tuosito.it
/var/www/altrosito.it
/var/www/altrositoancora.it

Teoricamente se facevi fopen('/var/www/altrosito.it/config.php'); (<--- dati alla connessione del database) ti veniva impedito l'accesso, ma se facevi una query con LOAD DATA leggevi tutto.

Ah la vulnerabilità nel 2008 era presente su quasi tutti servizi di hosting italiani che offrivano il solito pacchetto PHP/MYSQL (su quelli esteri non saprei), quindi la svista sarà pure da anni 90", ma a quanto pare è stata reiterata fino a quasi il 2010...

Comunque è stato solo un piccolo OT.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #7 il: Ottobre 18, 2017, 14:25 »
> La vulnerabilità (o mancanza di professionalità/svista chiamatela come vi pare)

no, non è questione di nomi, chiamala come ti pare, la sostanza è la stessa... Niente affatto. La sostanza non è la stessa. Una vulnerabilità è una cosa abbastanza ben precisa. La mancanza di professionalità è una cosa abbastanza ben precisa. E sono due cose precisamente diverse.

> Ah la vulnerabilità nel 2008 era presente su quasi tutti servizi di hosting italiani

Beh sì, non stento a crederlo.
Immagina di lasciare le chiavi di casa appese all'esterno della porta. Se i ladri entrano, questa non è una vulnerabilità della serratura, capisci.
Ora, immagina di essere il portiere di un albergo e di lasciare le chiavi di ogni singola stanza appese all'esterno della porta.
E poi se i ladri entrano, provaci a dire che è una vulnerabilità.

Comunque, il 2008 è abbastanza indietro nel tempo. Magari adesso sono diventati... meno vulnerabili, diciamo.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #8 il: Ottobre 18, 2017, 19:13 »
no, non è questione di nomi, chiamala come ti pare, la sostanza è la stessa... Niente affatto. La sostanza non è la stessa. Una vulnerabilità è una cosa abbastanza ben precisa. La mancanza di professionalità è una cosa abbastanza ben precisa. E sono due cose precisamente diverse.

Beh... se per questo la maggior parte delle vulnerabilità dipendono da una mancanza di professionalità.

Vedendo su wikipedia: Vulnerabilità software (bug software): Si presenta ovunque ci sia un difetto di progettazione, codifica, installazione e configurazione del software.

Vedila dal punto di vista di un attaccante, a lui, se ti ruba i dati dei clienti tramite una configurazione errata o perchè ti roota con un exploit... non gliene frega nulla...

Citazione
Comunque, il 2008 è abbastanza indietro nel tempo. Magari adesso sono diventati... meno vulnerabili, diciamo.
Lo spero anche io per loro :D

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #9 il: Ottobre 18, 2017, 22:22 »
No, di nuovo. Sono due cose diverse. Una vulnerabilità è per definizione inaspettata e non documentata. Può essere causata da mille cose tra cui un gatto che passeggia sulla tastiera e produce un commit non voluto. Non importa da cosa è causata. Non importa. Non importa. L'importante è che non si sa che c'è (a meno di non credere a teorie del complotto sulla cia e l'nsa). Poi qualcuno la trova e la sfrutta. Questa è una vulnerabilità. Questa.

Un altro paio di maniche interamente, è invece un comportamento perfettamente documentato, perfettamente noto, perfettamente prevedibile in ogni sua parte, e che pure qualcuno ha usato nel modo sbagliato. Come dire, questa è una pistola, impugnala, puntala sul tuo piede, premi il grilletto, il risultato sarà che ti farai male... e qualcuno lo stesso riesce a spararsi sul piede. Questa non è una vulnerabilità. Ripeto, non è una vulnerabilità. Ripeto ancora, non è una vulnerabilità. E' solo stupido. Ed è poco sensato riportare un incidende di questo tipo come una vulnerabilità, sarebbe come raccontare che uno si è sparato nel piede come un difetto della pistola. Non è una vulnerabilità, è stupidità. Ripeto, non è vulnerabilità, è stupidità.

Ora, a onor del vero il report farlocco che hai citato non si spinge fino al punto di dire che questa è una vulnerabilità di mysql. Parla di "normali installazioni debian", che è come dire "quello che ottieni se installi Debian alla niubba facendo sempre clic su ok". Che poi la maggior parte di chi mette in piedi un servizio basato su php+mysql faccia proprio una cosa del genere, ehm, ehm, ehm... ecco, come dire. Ma non è una vulnerabilità di mysql. Né di Debian, ovviamente. Semmai è una vulnerabilità di un particolare servizio di hosting. Ma allora se vuoi fare un report su *quella* vulnerabilità, lo devi fare per bene: caro servizio di hosting che inizia per A e finisce per A, guarda che stai fornendo installazioni di mysql parecchio mal configurate... eccetera eccetera. Ma non c'entrano mysql o debian, ripeto. Non è una vulnerabilità di mysql, né di debian, ripeto.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #10 il: Ottobre 18, 2017, 23:18 »
Guarda ora non per darti contro ma secondo me stai cavillando sulla terminologia ed è anche un pò discutibile quello che hai scritto: ho detto che è una vulnerabilità, non che sia specifica di MySQL o di Debian.

Citazione
Una vulnerabilità è per definizione inaspettata e non documentata. Può essere causata da mille cose tra cui un gatto che passeggia sulla tastiera e produce un commit non voluto.

Si in linea teorica ho capito cosa intendi, però a parte che il comportamento del gatto lo puoi prevedere con una adeguata esperienza (e chi ha un gatto lo sa) o con un minimo di immaginazione.

Poi non è vero perchè nella community hacking abbiamo tendenzialmente due movimenti distinti:
Nel primo quando qualcuno trova una vulnerabilità la prima cosa che fa è comunicarla ai maggiori siti web che si occupano di rilasciare exploits e/o notificare vulnerabilità con POC (es. exploit-db, 0day, ...).
Questo perchè alla fine i bug si basano sempre sugli stessi concetti, quindi le persone specializzate fanno semplicemente a gara a chi li trova prima.
Pubblicarli in ritardo vuol dire perdere l'autorialità, nonchè il prestigio.

Poi c'è a chi della fama non gliene frega niente e guarda l'aspetto ludico dell'hacking, quindi ciò che non guadagna in fama (pubblicando il bug appena trovato) lo guadagna in soldi nell'arco di tempo nel quale non lo trova qualcun'altro vendendolo e sfruttandolo.

Citazione
è invece un comportamento perfettamente documentato

Questo è sindacabile, perchè se è un comportamento perfettamente documentato che le cartelle devono essere settate con gli adeguati permessi, allora è anche un comportamento perfettamente documentato che se se non inserisci un token univoco in una richiesta POST rischi un attacco di tipo CSRF.


Preso dal sito  di Owsap

Citazione
A vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities that rely on the application. The term "vulnerability" is often used very loosely. However, here we need to distinguish threats, attacks, and countermeasures.

Quotando anche gli esempi:
Citazione
     Lack of input validation on user input
Lack of sufficient logging mechanism
Fail-open error handling
Not closing the database connection properly

Quando hai una funzionalità che può essere utilizzata in maniera impropria per ottenere dei vantaggi non previsti hai una vulnerabilità.

Buonanotte a tutti, vi auguro un felice risveglio!
« Ultima modifica: Ottobre 19, 2017, 03:16 da tommyb1992 »

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #11 il: Ottobre 19, 2017, 20:28 »
Si boh beh. Cioe' stiamo parlando del fatto che sia inaspettato che un comando che legge files riesca a leggere i files se il processo che lo esegue ha permessi adeguati?

Potremmo anche discutere se sia una buona idea il fatto che MySQL abbia un comando del genere. Comando che e' grosso modo equivalente ad open().read() in Python, per dire.
Il punto e' che o ci mettiamo ad aggiungere jailing granulare a tutto quello che ha un interprete di comandi (che ha un costo immenso), oppure ci mettiamo a fare i minuziosi con i permessi (... cioe', il processo di MySQL *deve* avere accesso ai suoi files di log, ma e' possibile che i files di log potrebbero essere configurati come write only per l'utente, per dire...). E stare attenti con i gruppi. Etc etc etc. E prima o poi qualcuno fa dei bachi nel jailing oppure fa una cacata con i permessi. Statisticamente succede.

Oppure ci rendiamo conto, appunto, che sono finiti gli anni 90. Se su una macchina ho su il database e l'attaccante puo' tirare comandi arbitrari in MySQL, ho gia' perso. Perche' sulla macchina la cosa piu' preziosa saranno precisamente i dati. E se ha SELECT ha tutto quello che c'e' di valore su quella macchina. Perche' su quella macchina non ci deve essere nient'altro se non lo stretto indispensabile. Ci saranno purtroppo un minimo di credenziali, con le quali potra' fare poco e nulla. E fine. Non c'e' bisogno di nient'altro.

Pero' mi verrebbe da dire... come ha fatto ad avere accesso a quel database? Molto probabilmente vuole dire che ha anche preso controllo di una delle macchine che hostano i servizi che leggono dal database oppure, peggio ancora, da una macchina di un operatore. Il che e' un problema *grosso* (cioe' se i ruoli sono ben separati neanche enorme, pero' dipende molto dalla cultura aziendale... specie all'inizio spesso tutti possono fare un po' di tutto). Perche' non c'e' nessuna ragione che qualcos'altro possa anche solo raggiungere a livello di networking quella macchina.

Questo sembra complicato? Bene, benvenuti nel 2017! Queste sono features di default o best practice di qualunque cloud provider che mi venga in mente. Perche' a me il walkman un po' manca, pero' ca**o come sono comodi i servizi di streaming...

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #12 il: Ottobre 20, 2017, 08:46 »
Ma sì, infatti, non si capisce di cosa stiamo parlando... voglio dire, qui la grande sorpresa sembra essere che non ci si può credere che un database abbia anche una funzione che accede a file arbitrari. Cos'altro si inventeranno questi giovani d'oggi, signora mia.
Che poi, ripeto, neanche quel rapporto di "vulnerabilità" tra molte virgolette che l'OP citava, si azzarda a dire esplicitamente che questa è una vulnerabilità di MySql, o di Debian per la sua configurazione standard. Il rapporto è farlocco se lo si interpreta come un rapporto di vulnerabilità, ma probabilmente voleva soltanto essere un amichevole consiglio di fare attenzione a come si configura un web server. E allora bene così.
Poi se un hosting italiano configura male il suo apache e ti permette di fare directory trasversing con MySql, allora questa è una vulnerabilità del servizio di hosting, non di MySql, non di Debian, non di Apache. E se l'hosting è correttamente configurato, allora resta solo di potenzialmente pericoloso il caso in cui tu permetti all'utente di lanciare query arbitrarie sul tuo database. Ma allora è una vulnerabilità del tuo sito, non di MySql, non di Debian, non di Apache, non dell'hosting.

Comunque per carità, non fidarti di quello che dico io. Se pensi che sia una vulnerabilità di MySql (ma allora anche di Postgres, e di parecchi altri RDBMS suppongo), o una vulnerabilità di Debian (ma allora anche di altre distribuzioni linux suppongo), e poi anche una vulnerabilità di Python come giustamente fa notare Riko, e di dozzine di altri ambienti di programmazione per quel che vale, allora ne hai di lavoro da fare: posta un ticket sul bug tracker di ciascuno di loro, e vediamo che cosa ti rispondono. Mettere insieme le risposte può essere uno step verso la comprensione di che cosa *è* una vulnerabilità e di cosa *non* lo è.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #13 il: Ottobre 20, 2017, 10:32 »
Se pensi che sia una vulnerabilità di MySql

Sai bene che non ho detto questo :)

Per me si può concludere la conversazione, non penso abbia alcuna utilità continuare...

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:[HackMe] Nuovo metodo più sicuro per storage di password
« Risposta #14 il: Ottobre 20, 2017, 17:59 »
Boh, tu hai parlato di una vulnerabilità. Probabilmente intendevi dire che i computer in generale sono strumenti pericolosi, a non leggere il manuale. E hai ragione, senza dubbio.