Topic: crittografare url da programma  (Letto 716 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Badly

  • python unicellularis
  • *
  • Post: 27
  • Punti reputazione: 0
    • Mostra profilo
crittografare url da programma
« il: Gennaio 18, 2016, 02:05 »
Salve a tutti, non è un vero e proprio progetto, e spero che la mia richiesta non sia considerata "magia"  :).
Ho, molto banalmente, fatto comunicare uno script con un sito web.
leggo la pagina web tramite "urllib.request.urlopen". Quel che mi storce il naso, è che l'url è visibile!
Voglio dire. la stringa corrispondente all'url è visibilissima da chiunque legga il sorgente, o chiunque decompili lo script.
Ho pensato a numerosi modi per crittografare l'url, inventandomi gli algoritmi più strani  :thinking:, ma la chiave?
Come faccio a tenerla segreta?
Ecco, la mia domanda è dunque, è possibile rendere segreto, ad esempio:
[codice]urllib.request.urlopen("http://www.sitobello.it/file.txt")[/codice]
in modo che solo per l'applicativo sia esplicito "www.sitobello.it" e non l'utente che decompila e/o guarda il sorgente?

Offline Tungsteno

  • python erectus
  • ***
  • Post: 183
  • Punti reputazione: 0
    • Mostra profilo
Re: crittografare url da programma
« Risposta #1 il: Gennaio 18, 2016, 02:25 »
Ciucciati questo! https://liftoff.github.io/pyminifier/    :D

A parte gli scherzi, se intendi la script in python (e non la comunicazione tra host e pagina web) penso che quella sopra possa fare al caso tuo. In ogni caso non conosco quanto possa essere efficace il suo algoritmo di offuscamento del codice (non l'ho mai testato a fondo e per ora non mi interessa), ma quanto meno ti dovrebbe coprire un pò le spalle (più che altro mettere l'anima in pace). Considera che essendo un programma di offuscamento non fa una reale "crittografia" del codice (immagino che tu intendessi la crittografia delle reti wifi, come paragone) ma tecnicamente modifica i nomi delle funzioni/variabili e/o aggiunge codice superfluo che rimanda a altro codice, etc. e poi comprime il tutto (in stile file min.js) e poi vabbò fa anche il classico zip(& fratelli).

Quindi vedi tu, sperò però che tu non stia programmando codice per la Nasa altrimenti ti conviene cambiare approccio.   :ok:
« Ultima modifica: Gennaio 18, 2016, 02:43 da Tungsteno »

Offline Giornale di Sistema

  • python sapiens sapiens
  • ******
  • Post: 3.124
  • Punti reputazione: 4
    • Mostra profilo
    • Distillato di Python
Re: crittografare url da programma
« Risposta #2 il: Gennaio 18, 2016, 08:30 »
Aggiungo, anche se non è fra le richieste dell'OP e senza aver visto il codice:
se c'è da lavorare molto di urllib, requests è una strada più larga e pulita.

Edit: non mi ero accorto avessero tradotto la documentazione in italiano.
« Ultima modifica: Gennaio 18, 2016, 08:33 da Giornale di Sistema »

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.020
  • Punti reputazione: 9
    • Mostra profilo
Re: crittografare url da programma
« Risposta #3 il: Gennaio 18, 2016, 10:08 »
Attenzione però, lo specifico use case dell'OP non c'entra niente con la sua richiesta. Lui vuole sapere come nascondere informazioni sensibili che finiscono dentro un modulo python... se non fosse una url in chiaro, potrebbe essere una password in chiaro, la chiave principale di django, l'email dello sviluppatore... qualunque cosa.

La risposta (chiara e semplice, una volta per tutte) è che non è possibile. Non esiste offuscatore, compilatore etc che ti renda sicuro. La soluzione è di non mettere questo genere di informazioni direttamente dentro il codice python, ma caricarle dinamicamente da una fonte esterna che si ritiene più protetta (che oltre a essere cosa buona per la sicurezza, è cosa ottima anche per la portabilità del sistema).
E dove le metto, queste informazioni, allora? Boh. Dipende dallo scenario in cui gira quel codice. Come caso estremo, se quel codice gira solo in locale sulla tua macchina, allora potresti pure mettere le informazioni sensibili direttamente dentro al codice. Se qualcuno riesce ad accedere al sorgente, vuol dire che comunque ha già i tuoi stessi privilegi di accesso sulla tua macchina, quindi sei fritto e panato a un livello ben più grave del tuo moduletto python.
Ovviamente, se anche solo vuoi pubblicare il tuo codice (metterlo su github, per dire), questo non va più bene. Allora, banalmente, metti queste informazioni in un file separato, per esempio un file json, e poi importale a runtime. Ovviamente includi questo file nella tua lista .gitignore, in modo che su github non verrà mai caricato.
Se poi il tuo codice fa parte di un'applicazione esposta sul web, allora il tuo file segreto dovrebbe naturalmente stare da qualche parte non esposta (e di nuovo... se qualcuno riesce ad arrivare fin lì, vuol dire che sei fritto e panato comunque). Molti PAAS (cfr Heroku) suggeriscono/impongono di mettere queste informazioni in variabili d'ambiente, e quindi il tuo codice python le recupera con os.environ. Questo è molto più pulito, perché così il tuo slug (l'impronta della tua applicazione) comprende solo le librerie (specificate da un requirement.txt) e il tuo codice (specificato da un punto di commit del tuo version control), senza nessun file spurio aggiunto. Ma chiaramente, per lo sviluppo in locale sulla tua macchina, di solito non vuoi creare decine di variabili d'ambiente solo per le tue prove...


Ma poi...


... naturalmente...


(ehm...)


invece mi è molto chiaro qual è il *vero* problema dell'OP (vediamo se indovino  ;) )
Lui ha un modulo python più o meno "standalone" che "distribuisce" nel senso che lo copia fisicamente su varie macchine, dove gira in locale. E naturalmente, anche se distribuisce solo il pyc, si è accorto che aprendo il pyc con un hex viewer i valori delle costanti in chiaro si leggono lo stesso... E quindi si chiede, come fare?... Ovviamente, vale la risposta di sopra: non c'è soluzione. Può comunque divertirsi un po' a offuscare le costanti, per esempio scrivendo ''.join(map(chr, [104, 101, 108, 108, 111])) per dire hello... così non ci sono costanti in chiaro, e per lo meno sposta di un millimetro più in alto l'asticella... per quel che vale.

Offline GlennHK

  • python sapiens sapiens
  • ******
  • Post: 1.655
  • Punti reputazione: 1
    • Mostra profilo
    • La Tana di GlennHK
Re: crittografare url da programma
« Risposta #4 il: Gennaio 18, 2016, 10:20 »
Ammesso e non concesso che si "crittografi" l'url anche col cifrario perfetto, a che pro?

Se non posso accedere al programma, non ha senso cifrare l'url.
Se vi posso accedere, lo faccio girare, metto uno sniffer e mi becco la richiesta, dove ovviamente c'è l'url.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: crittografare url da programma
« Risposta #5 il: Gennaio 18, 2016, 11:27 »
Oh, una delle mie tipologie di post preferite! Come oscuro un sorgente python, devo proteggere chissa' quale segreto.

Questo qui e' in una variabile un po' piu' interessante: ci si limita a chiedere come 'nascondere' un url. E' piu' interessante perche' la risposta al problema di "offuscare" il codice e' fondamentalmente: non farlo. E' un classico esempio di problema che ci si crea da soli e che non ha veramente soluzione nel dominio in cui la richiesta e' formulata.

Qui, tuttavia, la domanda e' un pochetto piu' interessante. E' "nuova".

Allora, come gia' fatto notare, il problema e' in effetti non un istanza del "come offusco". Offuscare e' una cattiva soluzione: si paga un costo non irrilevante per un beneficio trascurabile. Se non si vuole distribuire il sorgente, client/server e' l'unica cosa che funziona davvero.

Il problema e' un'istanza di "come tengo credenziali sicure". Si risolve in quello spazio.

Dopo di che, come fanno notare, se non si prendono altre precauzioni l'url puo' comunque essere dedotta. Volendo si potrebbe avere un proxy server considerato sicuro, fare solo ssl verso quello e a quel punto l'endpoint su cui finisci e' noto solo a chi gestisce il proxy. Che dovresti essere tu. Non e' chiaro a sto punto se il costo di mantenere un set di proxy ridondati sia minore di quello di tenere l'applicazione sul server.

Detto questo, non mi e' assolutamente chiaro perche' "proteggere" l'url... ma tant'e'.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.020
  • Punti reputazione: 9
    • Mostra profilo
Re: crittografare url da programma
« Risposta #6 il: Gennaio 18, 2016, 12:13 »
Riko, Glenn, state sovra-ingegnerizzando il problema... anche se capisco che così diventa interessante...

Ma davvero, l'impressione è che l'OP sia solo alla ricerca di qualcosa come ''.join(map(chr per camuffare un po' una costante in un pyc. Sarebbe già un traguardo se nel processo imparasse anche a tenere le costanti di configurazione separate dal resto del codice, e le informazioni sensibili separate dal resto della configurazione. Quando poi *davvero* avrà delle credenziali da tener sicure, allora sperabilmente sarà già in una mentalità client/server, magari userà django, leggerà le istruzioni per il deploy su qualche PAAS... insomma, ci penserà l'ambiente intorno a lui a guidarlo più o meno nella direzione giusta.
Oppure si troverà un sito porno in home page, certo.

Offline shinken

  • python erectus
  • ***
  • Post: 206
  • Punti reputazione: 0
    • Mostra profilo
Re: crittografare url da programma
« Risposta #7 il: Gennaio 18, 2016, 13:39 »
Sembra il problema di tutti di sistemi drm:
  • fornisci all' utente una scatola sigillata chiusa a chiave
  • perchè possa usarla(magari ti paga pure per usare il suo contenuto ) devi dagli una chiave...
  • e anche le istruzioni su come usare la chiave
  • e poi pensi davvero che l' utente non possa aprire la scatola e guardarci dento se ne ha voglia..

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: crittografare url da programma
« Risposta #8 il: Gennaio 19, 2016, 13:55 »
Riko, Glenn, state sovra-ingegnerizzando il problema... anche se capisco che così diventa interessante...

Mah, forse. La questione e'... quale e' il problema?

La richiesta e' *crittografare* l'url e gestire la chiave. Ora possiamo decidere che a lui basti "offuscare" l'url. Forse. A patto che sappia che ci sono altri metodi per vedere il dato che cerca di nascondere (a prescindere che faccia crittografia oppure "security through obscurity")... ovvero, se non si prende la briga di crittografare anche il traffico in uscita, e' chiaramente *inutile* ma proprio *inutile* ma realmente *inutile* qualunque passo preso in questa direzione. E' chiaro che e' inutile?

Se assumiamo che l'utente sappia decompilare un file python, dobbiamo anche assumere che sappia fare una fra le seguenti cose:
1. fare un tcpdump (o simile)
2. leggere la cache del dns locale della sua macchina

e forse anche:
3. accedere e/o spoofare il dns locale. e' la sua macchina: e' *banale*.

Quindi risolvere il problema a livello di codice e' semplicemente *inutile*. Possiamo parlarne a lungo, ma non portera' nessun beneficio concreto.
Si deve *per forza* prendere un approccio globale. Siccome se si vuole proteggere (o nascondere) qualcosa e' il link piu' debole quello che comanda, avere la migliore (o la peggiore) forma di protezione sull'url quando posso semplicemente vedere cosa sto facendo con tcpdump e' inutile.


Offline Giornale di Sistema

  • python sapiens sapiens
  • ******
  • Post: 3.124
  • Punti reputazione: 4
    • Mostra profilo
    • Distillato di Python
Re: crittografare url da programma
« Risposta #9 il: Gennaio 19, 2016, 15:04 »
Riko, Glenn, state sovra-ingegnerizzando il problema... anche se capisco che così diventa interessante...

Mah, forse. La questione e'... quale e' il problema?

Le esigenze dell'OP sono chiare:

Voglio dire. la stringa corrispondente all'url è visibilissima da chiunque legga il sorgente, o chiunque decompili lo script.

Può essere che non abbia presente tutti i risvolti che la discussione sta evidenziando e che magari porteranno l'OP a cambiare obiettivi,
ma di tutte le cose che si possono fare per recuperare l'URL, vuole almeno non sia leggibile guardando il sorgente o decompilando lo script.

Ora possiamo decidere che a lui basti "offuscare" l'url. Forse. A patto che sappia che ci sono altri metodi per vedere il dato che cerca di nascondere (a prescindere che faccia crittografia oppure "security through obscurity")...

Se OP torna a leggere la discussione senz'altro lo saprà.

se non si prende la briga di crittografare anche il traffico in uscita, e' chiaramente *inutile* ma proprio *inutile* ma realmente *inutile* qualunque passo preso in questa direzione. E' chiaro che e' inutile?

No, non sono sicuro di aver capito... intendi dire che non serve ad una beata ceppa?!?  :party:

Offline GlennHK

  • python sapiens sapiens
  • ******
  • Post: 1.655
  • Punti reputazione: 1
    • Mostra profilo
    • La Tana di GlennHK
Re: crittografare url da programma
« Risposta #10 il: Gennaio 19, 2016, 16:25 »
[codice]
url = open("url.txt").read().strip()
[/codice]

Più sicuro di così, solo con lo script non potrai mai capire quale sia l'url  :devil:

Offline shinken

  • python erectus
  • ***
  • Post: 206
  • Punti reputazione: 0
    • Mostra profilo
Re: crittografare url da programma
« Risposta #11 il: Gennaio 19, 2016, 16:40 »
Riko ha perfettamente ragione.
Una volta che si trasmette  un informazione se ne perde il controllo.
Trasmettere un testo criptato + algoritmo+chiave = trasmettere l' informazione, non facciamoci alcuna illusione.
Dietro questo sono stati spesi molti denari e molte illusioni ( protezioni drm, rotture di scatole a clienti paganti, royalty pagate per illudersi di avere una protezione ecc ecc ecc)

L' unica strada percorribile è di sterilizzare l' informazione rendendola non pericolosa quindi un lavoro dal lato del server che  penso rimanga sotto il controllo del Op.



Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.020
  • Punti reputazione: 9
    • Mostra profilo
Re: crittografare url da programma
« Risposta #12 il: Gennaio 19, 2016, 17:48 »
@ RIko etc.: ragazzi, avete ragione, ma fidatevi... l'OP *non* vuole davvero nascondere la url all'NSA.
L'OP ha solo fatto una richiesta che, a prenderla alla lettera, certo, richiede una risposta estremamente precisa. E glie l'abbiamo data, e se l'OP vorrà, ha tutti gli strumenti per iniziare a porsi il problema di come nascondere le url all'NSA.
Ma per il momento, tutto quello che l'OP vuole sapere è in sostanza come fare ad offuscare un po' una costante in un pyc ("decompilare" un pyc? Eh?!? Ma che roba è?). E può farlo, se vuole: gli abbiamo fatto vedere come. L'augurio è che, leggendo questo thread, abbia modo di riflettere anche sul fatto che dovrebbe imparare almeno a non mescolare costanti di configurazione all'interno del codice: questo sarebbe in ogni caso un traguardo alla sua portata, e gli sarebbe molto utile.
Poi l'augurio è anche che abbia capito che, *quando* davvero avrà bisogno di garantire la sicurezza delle credenziali di accesso, allora l'approccio dovrà essere completamente differente. Ma onestamente non sono sicuro che al momento sia il traguardo che si è posto (o comunque, alla sua portata).


Dopo di che, se vogliamo ancora restare in topic e sul filosofico, non tralascerei anche un'osservazione più pragmatica: il problema della sicurezza non è "tutto o niente" - c'è una gamma di opzioni, che hanno un costo, e in definitiva una convenienza. Puoi volere sicurezza, ma raramente questo vuol dire "a prova di NSA".
Se quello che vuoi fare è distribuire un modulo python copiandolo su una decina di macchine delle segretarie dell'ufficio, non vuoi mettere in piedi un server proxy e un tunnel ssl per garantire la sicurezza. Quello che *vuoi* fare, è offuscare due o tre costanti in un pyc (e ti sembra già tanto).
Spoiler: lo so, perché l'ho fatto. Uno stupido script che si loggava a un google drive e tirava su e giù dei file di testo. La password era appena appena offuscata nel pyc. Doveva servire come tampone per due mesi, l'ho scritto in un pomeriggio, e tutto è filato liscio. Nessuno ha decompilato il pyc, nessuno ha fatto un tcdump, nessuno ha usato uno sniffer. Sapevo che nessuno avrebbe fatto niente del genere, peraltro. La password era offuscata per mio divertimento personale, ma poteva restare in chiaro nel pyc: nessuno avrebbe mai pensato di aprire il pyc con un hex editor.
E' chiaro che in quei due mesi, invece, *qualcuno* avrebbe potuto fare tutto questo (brivido!). Ma a onor del vero, un hacker nordcoreano avrebbe potuto usare quei pc come zombi per scatenare un attacco nucleare, per quel che ne so. Più o meno le probabilità erano le stesse.
E' chiaro anche però che se devo fare qualcosa di più duraturo, e/o che potrebbe finire in mano a qualcuno un po' più determinato, allora mi pongo il problema.

Ma l'Op non è in questa condizione, perché (ed è una regola che vale in molti, molti casi)... se - lo - fosse - lo - saprebbe.

Quindi, in definitiva:

Riko:
> Si deve *per forza* prendere un approccio globale.

No, non sono d'accordo. Si deve *conoscere* il problema globale e sapere che esiste un approccio globale. Ma poi si prende di volta in volta l'approccio più pragmatico ed economico, valutando lo scenario.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: crittografare url da programma
« Risposta #13 il: Gennaio 19, 2016, 23:14 »
Dopo di che, se vogliamo ancora restare in topic e sul filosofico, non tralascerei anche un'osservazione più pragmatica: il problema della sicurezza non è "tutto o niente" - c'è una gamma di opzioni, che hanno un costo, e in definitiva una convenienza. Puoi volere sicurezza, ma raramente questo vuol dire "a prova di NSA".

Il problema di sicurezza e' tutto o niente. Chiedi a qualunque security engineer. Tutte le volte che la sicurezza e' un pensiero successivo, si fallisce. Che va benissimo se si opta per "nessuna sicurezza". Ma sicurezza "best effort" e' come dire *nessuna* sicurezza, non illudiamoci. Se e' ok non avere nessuna sicurezza, nessun problema.

La cosa interessante e' che i sistemi hanno la tendenza ad estendersi. E non e' infrequente che sistemi non critici diventino ad un tratto critici; e poi succedono macelli. Grossi. E semplicemente non se ne esce bene.

Ma al di la di questo... il problema e' semplice: se non hai bisogno di sicurezza perche' sei sicuro che i dati che hai non debbano essere protetti (e che non lo dovranno essere mai), allora non mettercela. Spendi il tempo per fare features; possibilmente servono a qualcosa. Fare finta sicurezza serve davvero a poco.

Perche' si... e' molto confortante dire ma si, metto un po' di sicurezza in modo da tagliare fuori l'80% dei malintenzionati. Magari capita anche che ad uno vada bene, l'unico attacco arriva da incompetenti e non succede nulla di male. Il problema e' che lo stesso discorso e' "il 20% dei malintenzionati possono fare quello che pare a loro del mio sistema". Il che vuole dire che se i miei dati devono essere sicuri, devo considerare che *non* sono sicuri. Puro e semplice.


Citazione
Se quello che vuoi fare è distribuire un modulo python copiandolo su una decina di macchine delle segretarie dell'ufficio, non vuoi mettere in piedi un server proxy e un tunnel ssl per garantire la sicurezza. Quello che *vuoi* fare, è offuscare due o tre costanti in un pyc (e ti sembra già tanto).
Spoiler: lo so, perché l'ho fatto. Uno stupido script che si loggava a un google drive e tirava su e giù dei file di testo. La password era appena appena offuscata nel pyc. Doveva servire come tampone per due mesi, l'ho scritto in un pomeriggio, e tutto è filato liscio. Nessuno ha decompilato il pyc, nessuno ha fatto un tcdump, nessuno ha usato uno sniffer. Sapevo che nessuno avrebbe fatto niente del genere, peraltro. La password era offuscata per mio divertimento personale, ma poteva restare in chiaro nel pyc: nessuno avrebbe mai pensato di aprire il pyc con un hex editor.

Ma non hai fatto sicurezza. Hai fatto una cosa, come dici, per tuo divertimento personale. Che va benissimo, basta essere onesti.
Non hai fatto "sicurezza". C'era bisogno di sicurezza? Probabilmente no. O forse si e vi e' andata bene (dipende insomma da cosa c'era in quel file).
Offuscare due o tre costanti in un pyc non e' sicurezza.

Citazione
E' chiaro che in quei due mesi, invece, *qualcuno* avrebbe potuto fare tutto questo (brivido!). Ma a onor del vero, un hacker nordcoreano avrebbe potuto usare quei pc come zombi per scatenare un attacco nucleare, per quel che ne so. Più o meno le probabilità erano le stesse.

Scusa un attimo... mi dici che potevi metterla in chiaro. Probabilmente avresti pure potuto metterla su un post-it su tutti gli schermi. Se il tuo servizio anche solo fosse stato in chiaro ma avesse usato POST invece che GET (che immagino siamo d'accordo *non* essere sicurezza in alcun modo) probabilmente nessuno avrebbe saputo accederlo senza il tuo applicativo.

Ma almeno avresti avuto chiaro che *non* stavi facendo sicurezza. Perche' voglio dire... le segretarie non distinguono il tasto on-off dall'accendisigari. Ma sai, capita che una abbia un figlio. O un amico del figlio. E per divertimento, eh, uno ci potaccia. Mica nemmeno malanimo. E poi succedono casini.

Citazione
> Si deve *per forza* prendere un approccio globale.

No, non sono d'accordo. Si deve *conoscere* il problema globale e sapere che esiste un approccio globale. Ma poi si prende di volta in volta l'approccio più pragmatico ed economico, valutando lo scenario.

Allora, scusa, ma e' semplicissimo. Se i dati devono essere protetti, si deve avere un sistema di sicurezza ben progettato. Non e' che nella maggior parte dei casi sia rocket science. Ci sono solo certe cose da fare e da non fare. Nota, e' solo un inizio. Ma almeno non si va in giro con le braghe calate. Se i dati vanno protetti, l'unico approccio e' progettare per bene. C'e' comunque il rischio di sbagliare (per cui a volte si paga gente per i pen test). Ma se non ci si prova nemmeno...

Se invece i dati *non* vanno protetti, beh, l'approccio piu' pragmatico ed economico e' *non* proteggerli. Affatto. Vuoi fare la password concatenando stringhe? Divertiti. Ma di fatto *non* stai proteggendo i dati; comunque.

Offline Badly

  • python unicellularis
  • *
  • Post: 27
  • Punti reputazione: 0
    • Mostra profilo
Re: crittografare url da programma
« Risposta #14 il: Gennaio 20, 2016, 17:32 »
Salve  ;), scusate se rispondo solo ora, ma ho il tempo molto frammentato :eyeroll:...
Wow! Non mi aspettavo arrivassero così tante risposte! E tra l'altro tutte (o quasi) esaustive!
Sì, quasi tutti hanno capito bene la mia richiesta!
Mi fa piacere che questa domanda sia stata reputata come "nuova", ma la mia era semplice curiosità.
In realtà è proprio la sicurezza dei dati che mi affascina. Ho utilizzato come esempio un URL, ma non c'è un vero motivo per cui "nasconderlo", è chiaro, se si sniffa il traffico si trova la richiesta  :) .
Ma era un esempio, come potrebbe essere un URL, potrebbe essere una password, o un qualsiasi dato sensibile che, ipotizzando di scegliere come strada quella di volerlo inserire nel sorgente (sconsigliatissimo e insicuro! Ma è pur sempre un alternativa sbrigativa), volevo sapere se "nascondere" ai futili umani il valore delle costanti, fosse considerata magia.
Ora so la risposta, sì :D .
No, scherzi a parte, prenderò come riferimento tutte le strade che mi avete gentilmente offerto. E ringrazio tutti per l'impegno che avete messo nell'aiutare un utente con una semplice curiosità!