Discussion:
Aruba e PEC - Password in CHIARO
(too old to reply)
Dario Fiumicello
2010-06-09 14:55:39 UTC
Permalink
Ciao a tutti

Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.

Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!

Personalmente mi sembra una grossa falla di sicurezza considerando che
la PEC ha valore legale e che:

- Se la password mi arriva in chiaro significa che sui loro DB Ú in
chiaro, e questo già non Ú bene
- La password arriva su una casella di posta classica, senza nessuna
cifratura!

Che ne pensate?
--
Dario Fiumicello
Manfredi
2010-06-10 09:29:03 UTC
Permalink
Post by Dario Fiumicello
- Se la password mi arriva in chiaro significa che sui loro DB Ú in
chiaro, e questo già non Ú bene
Ciao,
deduzione errata, non Ú detto che se ti "arriva" in chiaro la password, questa
sia conservata "in chiaro" sul DB.
Post by Dario Fiumicello
- La password arriva su una casella di posta classica, senza nessuna
cifratura!
Anche qui, la password viene inviata ad una casella di recovery, dichiarata al
momento della registrazione, che, quindi, viene implicitamente dichiarata "trusted".

Manfredi
Marco Ermini
2010-06-11 12:29:47 UTC
Permalink
Post by Dario Fiumicello
- Se la password mi arriva in chiaro significa che sui loro DB è in
  chiaro, e questo già non è bene
Ciao,
deduzione errata, non è detto che se ti "arriva" in chiaro la password, questa
sia conservata "in chiaro" sul DB.
Anche se non è conservata "in chiaro" vuol dire che è stata "criptata"
con un algoritmo reversibile, e quindi è un bug grave in ogni caso.
Forse un pochino meno grave, ma poco :-)

Non c'è alcun motivo di salvare una password in chiaro. Come qualsiasi
best practice degli ultimi 20 anni recita chiaramente, delle password
si conservano soltanto gli hash. Tra l'altro immagino che le aziende
che forniscano PEC debbano sottostare a requirement anche per quanto
riguarda la separazione delle responsabilità degli amministratori di
sistema - tenere le password in chiaro o facilmente reversibili sul DB
di sicuro non aiuta ad ottemperare questo requisito, visto che
qualsiasi DBA può copiarsi la lista delle password di tutti gli
utenti!
Post by Dario Fiumicello
- La password arriva su una casella di posta classica, senza nessuna
  cifratura!
Anche qui, la password viene inviata ad una casella di recovery, dichiarata al
momento della registrazione, che, quindi, viene implicitamente dichiarata "trusted".
Peccato che debba passare da per lo meno un paio di mailserver e una
certa rete chiamata "Internet" che tanto "trusted" non mi pare... non
so se tui hai la stessa opinione...


Cordiali saluti
--
Marco Ermini
***@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Manfredi
2010-06-11 16:09:12 UTC
Permalink
Post by Marco Ermini
Anche se non è conservata "in chiaro" vuol dire che è stata "criptata"
con un algoritmo reversibile, e quindi è un bug grave in ogni caso.
Forse un pochino meno grave, ma poco :-)
Se viene cifrata volutamente con un algoritmo reversibile, magari per motivi di
supporto, non vedo dove sia il bug, sempre che per bug si intenda un
comportamento non voluto/pensato del sistema.
Post by Marco Ermini
Peccato che debba passare da per lo meno un paio di mailserver e una
certa rete chiamata "Internet" che tanto "trusted" non mi pare... non
so se tui hai la stessa opinione...
Certo che non è trusted la rete. Sarebbe stato più opportuno che venisse inviata
una qualche procedura per il reset o il recupero della pwd, magari tramite web
in HTTPS.
Al solito, e mi dispiace doverlo constatare ancora, si deve mediare tra
sicurezza e usabilità/semplicità del sistema, soprattutto quando si deve
lavorare con i "final users".

Ciao,
Manfredi
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-12 13:28:13 UTC
Permalink
Post by Manfredi
Se viene cifrata volutamente con un algoritmo reversibile, magari per motivi di
supporto, non vedo dove sia il bug
Quali motivi di supporto possono rendere necessario conoscere la
password di un utente? (hint: inizia per "n" e finisce per "essuno").
Post by Manfredi
Sarebbe stato più opportuno che venisse inviata
una qualche procedura per il reset o il recupero della pwd, magari tramite web
in HTTPS.
Esattamente.
Post by Manfredi
Al solito, e mi dispiace doverlo constatare ancora, si deve mediare tra
sicurezza e usabilità/semplicità del sistema,
Dal momento che un reset o il "rimandare la password" richiedono
sostanzialmente lo stesso numero di click, non e' una mediazione: e' uno
sbaglio e basta.

Ne' la procedura con un reset "costa" di piu' (pieno il mondo di codice
per realizzarla). Quindi non se ne vede proprio la ragione, se non
semplice pressapochismo.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-12 13:40:30 UTC
Permalink
Post by Manfredi
Post by Marco Ermini
Anche se non è conservata "in chiaro" vuol dire che è stata "criptata"
con un algoritmo reversibile, e quindi è un bug grave in ogni caso.
Forse un pochino meno grave, ma poco :-)
Se viene cifrata volutamente con un algoritmo reversibile, magari per motivi di
supporto, non vedo dove sia il bug, sempre che per bug si intenda un
comportamento non voluto/pensato del sistema.
Non e` un bug, e` una mancanza. NON deve essere possibile risalire in
alcun modo alle password memorizzate nel DB. Proprio perche` la PEC ha
valore legale nessun altro se non il legittimo proprietario deve essere
in grado di usare/ottenere quella password.

In questo caso invece ci sarebbero almeno DUE persone in grado di
accedere a quelle password:

1) l'utente
2) il programmatore/sistemista che avesse accesso all'algoritmo di cifra
delle password.
Post by Manfredi
Post by Marco Ermini
Peccato che debba passare da per lo meno un paio di mailserver e una
certa rete chiamata "Internet" che tanto "trusted" non mi pare... non
so se tui hai la stessa opinione...
Certo che non è trusted la rete. Sarebbe stato più opportuno che venisse inviata
una qualche procedura per il reset o il recupero della pwd, magari tramite web
in HTTPS.
Al solito, e mi dispiace doverlo constatare ancora, si deve mediare tra
sicurezza e usabilità/semplicità del sistema, soprattutto quando si deve
lavorare con i "final users".
Ribadisco, la PEC ha valore LEGALE. Non e` assolutamente accettabile
abbassare a queto livello la sicurezza dell'intero sistema, che gia` di
per se e` una patacca.
Post by Manfredi
Ciao,
Manfredi
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-11 12:47:41 UTC
Permalink
Post by Manfredi
Post by Dario Fiumicello
- Se la password mi arriva in chiaro significa che sui loro DB Ú in
chiaro, e questo già non Ú bene
Ciao,
deduzione errata, non Ú detto che se ti "arriva" in chiaro la password, questa
sia conservata "in chiaro" sul DB.
Potra` anche essere salvata cifrata sul DB, ma per mandartela in chiaro
via mail vuol dire che la password di decodifica e` disponibile per il
programma che si occupa di inviare le mail di recupero. Il che apre
scenari catastrofici.
Post by Manfredi
Post by Dario Fiumicello
- La password arriva su una casella di posta classica, senza nessuna
cifratura!
Anche qui, la password viene inviata ad una casella di recovery, dichiarata al
momento della registrazione, che, quindi, viene implicitamente dichiarata "trusted".
Si`, ma ha la stessa sicurezza di inviare per posta ordinaria le chiavi
della porta blindata di casa tua, al tuo indirizzo di casa. Quest'ultima
sara` anche sicura, ma chiunque puo` prenderle.

Ovviamente tutto cio` permette ad Aruba (in questo caso) di abbattere i
costi di gestione. A tutto discapito della robustezza del servizio.
Dario Fiumicello - Antek
2010-06-11 16:52:57 UTC
Permalink
Il giorno Fri, 11 Jun 2010 14:47:41 +0200
Post by William Maddler
- Se la password mi arriva in chiaro significa che sui loro DB Ú
in chiaro, e questo già non Ú bene
Ciao,
deduzione errata, non Ú detto che se ti "arriva" in chiaro la
password, questa sia conservata "in chiaro" sul DB.
Potra` anche essere salvata cifrata sul DB, ma per mandartela in
chiaro via mail vuol dire che la password di decodifica e`
disponibile per il programma che si occupa di inviare le mail di
recupero. Il che apre scenari catastrofici.
- La password arriva su una casella di posta classica, senza
nessuna cifratura!
Anche qui, la password viene inviata ad una casella di recovery,
dichiarata al momento della registrazione, che, quindi, viene
implicitamente dichiarata "trusted".
Si`, ma ha la stessa sicurezza di inviare per posta ordinaria le
chiavi della porta blindata di casa tua, al tuo indirizzo di casa.
Quest'ultima sara` anche sicura, ma chiunque puo` prenderle.
L'esempio calza perfettamente!
Post by William Maddler
Ovviamente tutto cio` permette ad Aruba (in questo caso) di abbattere
i costi di gestione. A tutto discapito della robustezza del servizio.
Ma qui mi domando e chiedo: Una casella PEC che sia "certificata come
PEC" dovrà pur avere dei requisiti minimi di sicurezza che saranno
scritti da qualche parte (presumo)... Se esistono e se non sono fatti a
pene di segugio immagino ci sia anche qualche sezione dedicata alle
modalità di storage delle credenziali di accesso alla casella...

... o forse sono troppo ingenuo a crederlo? :)
--
Dario Fiumicello
Cristiano Deana
2010-06-11 12:57:50 UTC
Permalink
Post by Manfredi
Anche qui, la password viene inviata ad una casella di recovery, dichiarata al
momento della registrazione, che, quindi, viene implicitamente dichiarata "trusted".
E' "trusted" l'indirizzo email, magari non lo e' tutto quello che lo
riguarda: dal provider, alla connettvitia', ecc. ecc.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Dario Fiumicello
2010-06-11 13:49:42 UTC
Permalink
Il giorno Thu, 10 Jun 2010 11:29:03 +0200
Post by Manfredi
Anche qui, la password viene inviata ad una casella di recovery,
dichiarata al momento della registrazione, che, quindi, viene
implicitamente dichiarata "trusted".
Trusted??? E dove sta scritto? Implicitamente???

Comunque anche se fosse dichiarato non mi sembra affatto una procedura
corretta, secondo me andrebbe fatto solo il reset della password, mai
fatta viaggiare la password attuale in chiaro su una casella non PEC.
Questo a mio parere invalida tutta la sicurezza della PEC.
--
Dario Fiumicello
Manfredi
2010-06-11 16:53:59 UTC
Permalink
Post by Dario Fiumicello
Trusted??? E dove sta scritto? Implicitamente???
Ciao,
se ti viene chiesto di inserire un mail address per il recovery della password,
presumo che l'indirizzo mail che si inserisca sia considerato "buono"
dall'utente. Che poi non sia sicuro o che non sia la soluzione ottimale posso
essere concorde, ma sicuramente risolve i problemi ed abbassa i costi di
gestione del servizio.
Post by Dario Fiumicello
Comunque anche se fosse dichiarato non mi sembra affatto una procedura
corretta, secondo me andrebbe fatto solo il reset della password, mai
fatta viaggiare la password attuale in chiaro su una casella non PEC.
Questo a mio parere invalida tutta la sicurezza della PEC.
Concordo con te sulla sicurezza. Non pensavo di scatenare questo thread...

Non ho mai scritto che fosse giusto come comportamento, ma che nella visione del
gestore questo non è un bug (almeno spero che sia una cosa voluta per abbassare
i costi).

Come ha scritto bene Maddler, questo tipo di comportamento/compromesso, se mi
passate il termine, permette, infatti, al gestore, in questo caso Aruba, di
abbassare i costi di gestione a scapito della sicurezza.

Buona serata,
Manfredi
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-12 13:27:39 UTC
Permalink
Post by Manfredi
Post by Dario Fiumicello
Trusted??? E dove sta scritto? Implicitamente???
Ciao,
se ti viene chiesto di inserire un mail address per il recovery della password,
presumo che l'indirizzo mail che si inserisca sia considerato "buono"
dall'utente. Che poi non sia sicuro o che non sia la soluzione ottimale posso
essere concorde, ma sicuramente risolve i problemi ed abbassa i costi di
gestione del servizio.
Post by Dario Fiumicello
Comunque anche se fosse dichiarato non mi sembra affatto una procedura
corretta, secondo me andrebbe fatto solo il reset della password, mai
fatta viaggiare la password attuale in chiaro su una casella non PEC.
Questo a mio parere invalida tutta la sicurezza della PEC.
Concordo con te sulla sicurezza. Non pensavo di scatenare questo thread...
Non ho mai scritto che fosse giusto come comportamento, ma che nella visione del
gestore questo non è un bug (almeno spero che sia una cosa voluta per abbassare
i costi).
Come ha scritto bene Maddler, questo tipo di comportamento/compromesso, se mi
passate il termine, permette, infatti, al gestore, in questo caso Aruba, di
abbassare i costi di gestione a scapito della sicurezza.
Rendendo tutto il servizio appena poco piu` che inutile. Scopo
sostanziale della PEC e` *garantire* invio e contenuto delle
comunicazioni inviate tramite essa. Se manca la sicurezza anche in uno
solo anello della catena, tanto vale usare la posta elettronica
tradizionale.
Post by Manfredi
Buona serata,
Manfredi
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-13 11:57:14 UTC
Permalink
Post by William Maddler
Rendendo tutto il servizio appena poco piu` che inutile. Scopo
sostanziale della PEC e` *garantire* invio e contenuto delle
comunicazioni inviate tramite essa.
Per la precisione, lo scopo è garantire la generazione di una traccia
elettronica di consegna opponibile a terzi.

Fermo restando che questa procedura di password reminding e' SBAGLIATA,
in cosa questa procedura mina lo scopo sostanziale della PEC?

Esatto, in nulla. Ovviamente e' SBAGLIATA da un punto di vista logico e
di security, ma NON mina lo scopo della PEC. Che e' il motivo per cui
non fa parte delle specifiche e dei requisiti per la PEC ;-)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
William Maddler
2010-06-13 19:34:32 UTC
Permalink
Post by Stefano Zanero
Post by William Maddler
Rendendo tutto il servizio appena poco piu` che inutile. Scopo
sostanziale della PEC e` *garantire* invio e contenuto delle
comunicazioni inviate tramite essa.
Per la precisione, lo scopo è garantire la generazione di una traccia
elettronica di consegna opponibile a terzi.
Fermo restando che questa procedura di password reminding e' SBAGLIATA,
in cosa questa procedura mina lo scopo sostanziale della PEC?
Esatto, in nulla. Ovviamente e' SBAGLIATA da un punto di vista logico e
di security, ma NON mina lo scopo della PEC. Che e' il motivo per cui
non fa parte delle specifiche e dei requisiti per la PEC ;-)
Beh, se perdere traccia del reale mittente non e` rendere inutile il
servizio di Poste Elettronica Certificata.

Poi che il servizio resti sostanzialmente integro dal punto di vista
filosofico/tecnico possiamo anche essere d'accordo.

Se io prendo la tua password di PEC e invio al posto tuo e` vero che lo
scopo di "garanzia" della PEC viene assolto, ma sta certificando
l'autenticita` di una mail finta. No? :)
Post by Stefano Zanero
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-14 19:48:13 UTC
Permalink
Post by William Maddler
Beh, se perdere traccia del reale mittente non e` rendere inutile il
servizio di Poste Elettronica Certificata.
No, infatti non lo e'.
Post by William Maddler
Se io prendo la tua password di PEC e invio al posto tuo e` vero che lo
scopo di "garanzia" della PEC viene assolto, ma sta certificando
l'autenticita` di una mail finta. No? :)
No, perche' la PEC (aredaje!) non certifica l'autenticita' della mail,
ma GENERA UNA RICEVUTA DI CONSEGNA OPPONIBILE A TERZI.

Ti hanno mai chiesto una carta d'identita' per spedire una raccomandata?
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
William Maddler
2010-06-14 22:56:44 UTC
Permalink
Post by Stefano Zanero
Post by William Maddler
Beh, se perdere traccia del reale mittente non e` rendere inutile il
servizio di Poste Elettronica Certificata.
No, infatti non lo e'.
Post by William Maddler
Se io prendo la tua password di PEC e invio al posto tuo e` vero che lo
scopo di "garanzia" della PEC viene assolto, ma sta certificando
l'autenticita` di una mail finta. No? :)
No, perche' la PEC (aredaje!) non certifica l'autenticita' della mail,
ma GENERA UNA RICEVUTA DI CONSEGNA OPPONIBILE A TERZI.
Ti hanno mai chiesto una carta d'identita' per spedire una raccomandata?
Ok, ma allora per lo stesso discorso, visto che alle poste non mi
chiedono nulla per spedire la raccomandata, tantovale eliminare anche
username e password.

Ho capito perfettamente che la garanzia del mittente non fa parte delle
funzionalita` specifiche della PEC. Ma non puoi neanche dire "e chi se
ne frega se il mittente e` un altro" scusa... a questo punto eliminiamo
il 50% delle credenziali di accesso ai servizi vari ed eventuali e ale`!
Siamo tutti piu` felici. A questo punto usiamo tutti una bella identita`
collettiva, chiamiamoci tutti Luther Blisset e via cosi`.

Per come la vedo io, il tuo discorso fila da un punto di vista fila da
un punto di vista prettamente filosofico e squisitamente procedurale.

Dal punto di vista funzionale e di uso *a me* "me par' 'na strunzat'" :)

Comunque, credo che sopravviveremo entrambi, anche se restiamo di pareri
diversi :)
Claudio Telmon
2010-06-16 10:03:53 UTC
Permalink
...
Post by William Maddler
Post by Stefano Zanero
Ti hanno mai chiesto una carta d'identita' per spedire una
raccomandata?
Ok, ma allora per lo stesso discorso, visto che alle poste non mi
chiedono nulla per spedire la raccomandata, tantovale eliminare anche
username e password.
Infatti, sarebbe molto più coerente, se l'idea fosse che la casella
mittente non rilevi e che l'unica autenticazione sia una firma
elettronica del messaggio: perché non avere semplicemente un servizio
per l'invio (con una registrazione solo per l'addebito del pagamento) e
la casella PEC solo per la ricezione? Dopotutto, se non ti chiedo la
carta di identità per una raccomandata...

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-17 11:54:18 UTC
Permalink
Post by Claudio Telmon
Infatti, sarebbe molto più coerente, se l'idea fosse che la casella
mittente non rilevi e che l'unica autenticazione sia una firma
Non e' "se fosse". Questa E' l'idea. E' anche la legge che dice cosi' :)
Post by Claudio Telmon
perché non avere semplicemente un servizio
per l'invio (con una registrazione solo per l'addebito del pagamento) e
la casella PEC solo per la ricezione?
Che differenza fa? Considerando che ti serve una soluzione per garantire
la consegna della ricevuta...
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Telmon
2010-06-17 22:26:58 UTC
Permalink
Post by Stefano Zanero
Post by Claudio Telmon
Infatti, sarebbe molto più coerente, se l'idea fosse che la casella
mittente non rilevi e che l'unica autenticazione sia una firma
Non e' "se fosse". Questa E' l'idea. E' anche la legge che dice cosi' :)
Non mi pare che la legge dica che il mittente non rilevi, ma mi farebbe
piacere che mi indicassi dove lo dice. Mi pare al più che non dica
esplicitamente che il mittente è dato per autentico, cosa che lascia
l'autenticità del messaggio nella valutazione del giudice. In compenso,
leggendo la legge (nella mia ignoranza) vedo molte affermazione sul
'mittente" che non sembrano fare grande differenza fra persona mittente
e casella mittente, e indicazioni sulla sicurezza del canale fra gestore
e mittente, il che rende l'autenticità del messaggio più certa che con
un messaggio inviato da una casella qualsiasi. In queste condizioni, io
non avrei proprio voglia di trovarmi in un contenzioso con una PA e
sperare che il giudice giudichi a mio favore, "solo" perché io affermo
che la mia casella è stata utilizzata da terzi.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Telmon
2010-06-16 09:50:54 UTC
Permalink
Post by Stefano Zanero
No, perche' la PEC (aredaje!) non certifica l'autenticita' della mail,
ma GENERA UNA RICEVUTA DI CONSEGNA OPPONIBILE A TERZI.
Tecnicamente hai ragione, naturalmente, ma questo non vuole dire che il
fatto che qualcuno possa mandare mail da una tua casella PEC non ti
possa causare molte più seccature (e costi) dell'invio da una casella
normale.

A parte questo, l'accesso alla casella permette di rimuovere messaggi
che risultano, quelli sì, legalmente consegnati a te. Quindi la password
va protetta ;)
Post by Stefano Zanero
L'esempio sulla raccomandata l'abbiamo gia' fatto 100 volte, la posta
certificata crea un obbligo in capo al destinatario di controllare la
casella, e' vero, e' cosi', e' diverso dalla raccomandata cartacea, ha
lo stesso valore, fatevene una ragione.
L'abbiamo fatto perché è così che viene presentata anche da chi ha fatto
la legge. Questo vuole dire che le norme che si appoggiano alla PEC
saranno pensate come se fosse una normale raccomandata, e a quel punto
il fatto che qualche tecnico sappia che il meccanismo è diverso sarà
irrilevante.

Comunque penso che sia un falso problema, perché una volta tanto la
questione non è tecnica: ogni volta che ho fatto presente a qualcuno che
mentre con la raccomandata i termini della consegna di una multa partono
da quando ritiri la lettera, mentre con la PEC partono dalla consegna in
casella, anche se sei in ferie, hanno tutti ben capito il problema.
Quindi questo punto secondo me verrà cambiato *molto* presto.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Roberto Scaccia
2010-06-27 20:46:04 UTC
Permalink
"Ti hanno mai chiesto una carta d'identita' per spedire una raccomandata?"

Mi sembra una sintesi eccezionale del perché la PEC non garantisce
l'autenticità del messaggio (che può essere raggiunta con una bella
firma digitale del contenuto....analoga alla firma del pezzo di carta
inserito nella busta ed inviato via Posta Raccomandata).

Questo me lo segno nel taccuino dei controesempi da tirare fuori al
momento giusto!
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Pandolfi
2010-06-30 12:31:48 UTC
Permalink
Post by Stefano Zanero
No, perche' la PEC (aredaje!) non certifica l'autenticita' della mail,
ma GENERA UNA RICEVUTA DI CONSEGNA OPPONIBILE A TERZI.
concordiamo tutti.
Post by Stefano Zanero
Ti hanno mai chiesto una carta d'identita' per spedire una raccomandata?
no, ma per il rilascio della pec, si, mi hanno chiesto la c.i.
quindi come la mettiamo?

Marco Pandolfi



--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
VOGLIA DI VACANZE ?
* A Riccione i Riviera Park Hotels sono gli alberghi specializzati per le vacanze nei parchi divertimento.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=10604&d=30-6
Claudio Telmon
2010-06-13 11:37:27 UTC
Permalink
Post by Manfredi
Non ho mai scritto che fosse giusto come comportamento, ma che nella visione del
gestore questo non è un bug (almeno spero che sia una cosa voluta per abbassare
i costi).
Se non è un bug del gestore è un bug nelle specifiche per essere
accreditati come gestore di PEC, dato che degrada la sicurezza di una
casella PEC alla sicurezza di una casella qualsiasi.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
chopinx04
2010-06-11 23:06:48 UTC
Permalink
[....]
stavo leggendo il thread e quindi mi e' sorto il dubbio: ma allora
cosa dovrebbe fare Aruba o qualsiasi ISP che fornisce servizi PEC?

Di fatto se la password viene salvata con hash nel database, allora la
cosa piu' opportuna resettarla con una password causale e inviare
l'email al richiedente con la password stessa, ma come si diceva in
precedenza questo e' comunque insicuro perche' il destinatario
potrebbe essere malicious, il mezzo e' insicuro e cosi' via...

Anche se si procedesse (come mi pare facciano certi) con l'invio di un
email con un link random valido per un tot di ore per resettare la
password incorriamo sempre nella situazione precedente.

Allora, dopo tutto questo, mi chiedo: e' proponibile per questo tipo
di servizi obbligare i clienti ad avere una chiave asimmetrica di
qualche tipo cosi' che l'email contenente la password resettata o il
link o qualsiasi altra soluzione possa essere cryptata lato server con
la chiave pubblica del cliente? O secondo voi una soluzione del genere
e' troppo sofisticata?
Secondo me a senso proprio per il fatto che la PEC ha valore legale.

Saluti e buona serata,
0x412E

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-12 13:35:59 UTC
Permalink
Post by chopinx04
[....]
stavo leggendo il thread e quindi mi e' sorto il dubbio: ma allora
cosa dovrebbe fare Aruba o qualsiasi ISP che fornisce servizi PEC?
Di fatto se la password viene salvata con hash nel database, allora la
cosa piu' opportuna resettarla con una password causale e inviare
l'email al richiedente con la password stessa, ma come si diceva in
precedenza questo e' comunque insicuro perche' il destinatario
potrebbe essere malicious, il mezzo e' insicuro e cosi' via...
Invio via email, all'indirizzo fornito al momento della registrazione,
di una one time password per l'accesso alla pagina web di reset e
richiesta della "risposta magica".
Post by chopinx04
Anche se si procedesse (come mi pare facciano certi) con l'invio di un
email con un link random valido per un tot di ore per resettare la
password incorriamo sempre nella situazione precedente.
No, la "domanda salvapassword" serve proprio a questo. Ci sono un paio
di accortezze da prendere (ad esempio evitare date di nascita e cose
"ovvie") ma se implementata decentemente funziona.
Post by chopinx04
Allora, dopo tutto questo, mi chiedo: e' proponibile per questo tipo
di servizi obbligare i clienti ad avere una chiave asimmetrica di
qualche tipo cosi' che l'email contenente la password resettata o il
link o qualsiasi altra soluzione possa essere cryptata lato server con
la chiave pubblica del cliente? O secondo voi una soluzione del genere
e' troppo sofisticata?
Fondamentalmente complicato. E soprattutto entri in un loop infinito se
l'utente perde anche la sua chiave asimmetrica. ;)
Post by chopinx04
Secondo me a senso proprio per il fatto che la PEC ha valore legale.
Anche per questo cappellate come quella di Aruba sono estremamente gravi.
Post by chopinx04
Saluti e buona serata,
0x412E
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Telmon
2010-06-13 12:39:02 UTC
Permalink
Post by William Maddler
No, la "domanda salvapassword" serve proprio a questo. Ci sono un paio
di accortezze da prendere (ad esempio evitare date di nascita e cose
"ovvie") ma se implementata decentemente funziona.
La cattiva scelta delle domande/risposte da parte dell'utente non è un
problema di implementazione, ma di uso. Le caselle PEC sono pensate per
finire in mano ad ogni cittadino, volente o nolente, compresi quelli che
l'informatica non la capiscono, non la sopportano e finora l'hanno
sempre evitata. Dato che fornisce dei servizi con un certo valore
legale, le specifiche del servizio dovrebbero garantire una protezione
adeguata sia al valore legale che alle competenze medie del cittadino
che la dovrà usare.

Personalmente sono poco convinto dell'efficacia di un meccanismo di
"domanda salvapassword", particolarmente in un caso come la PEC.
Pensando a cos'ha di interessante una casella di posta PEC per un
attaccante, secondo me se ne dedice che gli attaccanti più probabili
sono persone che hanno in qualche modo a che fare con il titolare, e che
quindi hanno la più alta probabilità di conoscere la risposta alla domanda.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-13 19:38:18 UTC
Permalink
Post by Claudio Telmon
Post by William Maddler
No, la "domanda salvapassword" serve proprio a questo. Ci sono un paio
di accortezze da prendere (ad esempio evitare date di nascita e cose
"ovvie") ma se implementata decentemente funziona.
La cattiva scelta delle domande/risposte da parte dell'utente non è un
problema di implementazione, ma di uso.
Anche.
Post by Claudio Telmon
Le caselle PEC sono pensate per
finire in mano ad ogni cittadino, volente o nolente, compresi quelli che
l'informatica non la capiscono, non la sopportano e finora l'hanno
sempre evitata. Dato che fornisce dei servizi con un certo valore
legale, le specifiche del servizio dovrebbero garantire una protezione
adeguata sia al valore legale che alle competenze medie del cittadino
che la dovrà usare.
Si`, ma se raggioni cosi` allora buonanotte.
Una cosa e` rendere facile e comprensibile un servizio e l'accesso al
servizio stesso. Altra cosa e` fare cappellate nel tentativo di rendere
tutto eccessivamente semplice.

Lasciare che l'utente possa usare "123456" certo rende piu` facile per
un utente cambiare la password. Ma cosa succede dopo?
Post by Claudio Telmon
Personalmente sono poco convinto dell'efficacia di un meccanismo di
"domanda salvapassword", particolarmente in un caso come la PEC.
Pensando a cos'ha di interessante una casella di posta PEC per un
attaccante, secondo me se ne dedice che gli attaccanti più probabili
sono persone che hanno in qualche modo a che fare con il titolare, e che
quindi hanno la più alta probabilità di conoscere la risposta alla domanda.
Ok, allora siccome e` probabile che l'assassino e` sempre il maggiordomo
lasciamo le porte di casa aperte?
Post by Claudio Telmon
ciao
- Claudio
Claudio Telmon
2010-06-14 22:59:13 UTC
Permalink
...
Post by William Maddler
Dato che fornisce dei servizi con un certo valore legale, le
specifiche del servizio dovrebbero garantire una protezione
adeguata sia al valore legale che alle competenze medie del
cittadino che la dovrà usare.
Si`, ma se raggioni cosi` allora buonanotte.
Quale parte non ti piace? Che debba fornire una sicurezza adeguata al
valore del servizio, o che debba essere adeguato alle competenze di chi
lo deve usare?
Post by William Maddler
Una cosa e` rendere facile e comprensibile un servizio e l'accesso
al servizio stesso. Altra cosa e` fare cappellate nel tentativo di
rendere tutto eccessivamente semplice.
Sono d'accordo. Infatti, usare le domande salvapassword in questo
contesto mi sembra rientri nel secondo caso.
Post by William Maddler
Lasciare che l'utente possa usare "123456" certo rende piu` facile
per un utente cambiare la password. Ma cosa succede dopo?
Cosa c'entra?
Post by William Maddler
Personalmente sono poco convinto dell'efficacia di un meccanismo
di "domanda salvapassword", particolarmente in un caso come la
PEC. Pensando a cos'ha di interessante una casella di posta PEC per
un attaccante, secondo me se ne dedice che gli attaccanti più
probabili sono persone che hanno in qualche modo a che fare con il
titolare, e che quindi hanno la più alta probabilità di conoscere
la risposta alla domanda.
Ok, allora siccome e` probabile che l'assassino e` sempre il
maggiordomo lasciamo le porte di casa aperte?
Non so se interpreto bene quello che dici, ma stai attivando un
meccanismo per proteggerti dagli sconosciuti, che di fatto rende più
semplice l'attacco ai "parenti prossimi", che sono gli attaccanti più
probabili. Non mi sembra una buona idea. Chiudere la porta di casa non
rende più facile al maggiordomo l'omicidio, questo sì.
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-16 10:10:54 UTC
Permalink
Post by Claudio Telmon
...
Post by William Maddler
Dato che fornisce dei servizi con un certo valore legale, le
specifiche del servizio dovrebbero garantire una protezione
adeguata sia al valore legale che alle competenze medie del
cittadino che la dovrᅵ usare.
Si`, ma se raggioni cosi` allora buonanotte.
Quale parte non ti piace? Che debba fornire una sicurezza adeguata al
valore del servizio, o che debba essere adeguato alle competenze di chi
lo deve usare?
Post by William Maddler
Una cosa e` rendere facile e comprensibile un servizio e l'accesso
al servizio stesso. Altra cosa e` fare cappellate nel tentativo di
rendere tutto eccessivamente semplice.
Sono d'accordo. Infatti, usare le domande salvapassword in questo
contesto mi sembra rientri nel secondo caso.
Post by William Maddler
Lasciare che l'utente possa usare "123456" certo rende piu` facile
per un utente cambiare la password. Ma cosa succede dopo?
Cosa c'entra?
C'entra nella misura in cui una corretta gestione delle credenziali di
accesso ad in servizio, quale che questo sia, puo` contribuire a
renderlo piu` sicuro. Non "del tutto" sicuro, ma "piu`" sicuro.

Ovvio che se cio` non viene percepito come una necessita`, o un valore
aggiunto?, inutile starne a parlare.
Post by Claudio Telmon
Post by William Maddler
Personalmente sono poco convinto dell'efficacia di un meccanismo
di "domanda salvapassword", particolarmente in un caso come la
PEC. Pensando a cos'ha di interessante una casella di posta PEC per
un attaccante, secondo me se ne dedice che gli attaccanti piᅵ
probabili sono persone che hanno in qualche modo a che fare con il
titolare, e che quindi hanno la piᅵ alta probabilitᅵ di conoscere
la risposta alla domanda.
Ok, allora siccome e` probabile che l'assassino e` sempre il
maggiordomo lasciamo le porte di casa aperte?
Non so se interpreto bene quello che dici, ma stai attivando un
meccanismo per proteggerti dagli sconosciuti, che di fatto rende piᅵ
semplice l'attacco ai "parenti prossimi", che sono gli attaccanti piᅵ
probabili. Non mi sembra una buona idea. Chiudere la porta di casa non
rende piᅵ facile al maggiordomo l'omicidio, questo sᅵ.
Infatti stiamo parlando di un compromesso tra sicurezza e "facilita`" di
accesso ad un servizio, in questo caso il reset di una password.

Volendo escludere il test del DNA, e anche la' in caso di gemelli
omozigoti potrebbero esserci problemi ;)

Che ci sia qualcuno a te vicino che possa conoscere la risposta alla
domanda ovviamente non si puo` escludere. Ma ripeto, stiamo parlando di
un compromesso.

Il fatto che una soluzione non ti possa offrire una protezione al 100%
non e` una buona motivazione per non usarla. Un profilattico ha un
rischio di fallimento nella prevenzione delle gravidanze attorno al 3%,
che fai non lo usi? ;) Certo il "parente prossimo" puo` avertelo bucato...

Tornando alla tecnologia, non sto dicendo che la domanda salvapassword
sia la soluzione a tutti i mali delle password, dico solo che e` di
almeno un ordine di grandezza meglio che inviare una password in chiaro
via mail.

William
Claudio Telmon
2010-06-17 23:00:34 UTC
Permalink
Post by William Maddler
Infatti stiamo parlando di un compromesso tra sicurezza e "facilita`" di
accesso ad un servizio, in questo caso il reset di una password.
...
Post by William Maddler
Il fatto che una soluzione non ti possa offrire una protezione al 100%
non e` una buona motivazione per non usarla. Un profilattico ha un
rischio di fallimento nella prevenzione delle gravidanze attorno al 3%,
che fai non lo usi? ;) Certo il "parente prossimo" puo` avertelo bucato...
Secondo me non ci siamo :)
Mi piacerebbe discuterne in termini di minacce, impatti e rischio,
altrimenti non facciamo altro che tirare fuori iperboli di poca utilità.
Un meccanismo non è valido "in generale", e un compromesso è accettabile
in un caso e non in un altro.

La prima domanda è "a chi può interessare mettere le mani sulla mia
casella PEC"? La mia risposta è che una persona vicina all'intestatario
è una minaccia molto più probabile e motivata di una
persona/malintenzionato qualsiasi. Tanto per fare un esempio, nel corso
di un divorzio il coniuge può essere interessato a farmi una
comunicazione "certificata" e poi a farla sparire in modo che io non ne
venga a conoscenza e non la legga. Naturalmente, se vuoi puoi mettere in
discussione questa mia ipotesi, e allora discutiamo giustamente prima
delle minacce e degli impatti, e solo poi dei meccanismi.

In queste ipotesi, l'attaccante più probabile e motivato è quello che ha
più probabilità di conoscere la risposta alla domana segreta, e direi
che la probabilità è *molto* alta nella maggior parte dei casi
(lasciando perdere i casi in cui la domanda segreta è prefissata fra un
numero limitato di scelte, fra le quali "il nome di tua madre da nubile"
, cosa che in un paese conoscono tutti).

Allora, se parliamo di compromessi fra sicurezza e usabilità, io ritengo
che in questo caso la sicurezza aggiunta da un meccanismo di questo tipo
sia prossima allo zero, e nel caso (che spero non stiamo considerando)
in cui dando la risposta giusta hai direttamente la possibilità di
accedere alla casella, la sicurezza sia anzi diminuita.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
r***@serge.it
2010-06-16 10:41:22 UTC
Permalink
Post by Claudio Telmon
Personalmente sono poco convinto dell'efficacia di un meccanismo
di "domanda salvapassword", particolarmente in un caso come la
PEC. Pensando a cos'ha di interessante una casella di posta PEC per
un attaccante, secondo me se ne dedice che gli attaccanti più
probabili sono persone che hanno in qualche modo a che fare con il
titolare, e che quindi hanno la più alta probabilità di conoscere
la risposta alla domanda.
Ciao,

gestire le password in chiaro rispetto a farlo con qualsiasi meccanismo non
reversibile porta via lo stesso tempo per chi scrive codice.
Cosa mi cambia a fare una query nel db con la password "pluto" o con l'md5
di pluto?

Poi e' chiaro che se non ho una password da mandare all'utente in caso di
recovery sono "costretto" ad utilizzare meccanismi di conferma e a procedure
di reset (e meno male....).
Non stiamo parlando di contare i tachioni ma di cose relativamente semplici
da implementare.

Dopodiche' ricevi un link sulla mail definita come "trusted" e attraverso
quel link
accedi ad una pagina dove puoi cambiare la password.

Quindi non solo devi conoscere lo user, non solo devi conoscere le risposte
alle "domande salvapassword", ma poi devi anche avere accesso alla mailbox
per poter cambiare la password.
In tutto cio' la tua password non compare mai se non quando fai il post
(magari in https) nel momento in cui la salvi.

Lato utente non cambia quasi nulla.
Poi e' chiaro che se io come risposta alla domanda segreta in ogni sito uso
"XX4c%vR&&£" indipendentemente
dal fatto che mi chiedano il nome del cane o del gatto o di mia mamma da
nubile, tutti i discorsi sulla "probabilita' di conoscere la risposta" vanno
a farsi friggere.

Per chi programma ci sono infiniti script, template e tutorial per ispirarsi
e poter gestire in modo piu' sicuro di cio' che e' stato descritto riguardo
Aruba.

Per quanto riguarda lo scopo:
La PEC certifica l'avvenuta consegna? Si.
Se poi il livello di sicurezza non e' soddisfacente per l'utente questo puo'
sicuramentre trovare prodotti
all'altezza delle sue aspettative.

A mio avviso, indipendentemente dal tipo di servizio, PEC o posta normale,
mi sembra egualmente grave la mancanza di procedure di reset come hanno
anche la maggiorparte dei piu' sfigati software webbased free e,
soprattutto, che
la password sia inviata in chiaro.

RiCiao

Renato Serge

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marcello Magnifico
2010-06-17 12:55:53 UTC
Permalink
Risposta multipla. :-)
Post by Claudio Telmon
Dopotutto, se non ti chiedo la
carta di identità per una raccomandata...
Volendo saltare l'esempio -comunque assai pericoloso- della rimozione
di messaggi in luogo del legittimo destinatario, visto che qualcuno si
e' gia' dato la pena di spiegarlo, il caso dell'invio, forse, lo si
affronta piu' chiaramente da un punto di vista normativo.

E' pur vero che nessuno chiede un documento di identita' a chi spedisce
una raccomandata (cartacea o PEC, poco importa) in un contesto in cui
cio' e' obbligatorio per la comunicazione di atti ufficiali. Se, pero',
qualcuno lo fa senza essere il legittimo mittente o un soggetto che
opera in nome e per conto suo, probabilmente incorre nel reato di
"falso" o in una sua qualche variante. Il soggetto e' reso responsabile
di cio', non dalla tecnologia, ma dalla legge tout court.

Da un punto di vista tecnico, cio' e' molto brutto, poiche' si vorrebbe
che la tecnica fosse/creasse IL vincolo per cio' che si puo' o non si
puo' "davvero" fare. Forse la critica maggiore che si puo' muovere alla
PEC e' proprio quella di avere trasposto in modo troppo fedele un
contesto materiale, nato gia' vulnerabile ad abusi di un certo tipo, in
forma elettronica.

Cio' non legittima comunque, a mio avviso, un database di password in
chiaro, quando soluzioni di profilo ben piu' basso (>90% dei server di
posta elettronica non-PEC, >90% delle applicazioni web indipendentemente
dal loro scopo) dispongono comunque di meccanismi enormemente piu'
sicuri.
Post by Claudio Telmon
Non stiamo parlando di contare i tachioni ma di cose relativamente semplici
da implementare.
E' allarmante, inoltre, la frequenza con la quale si legge di scelte
implementative non soltanto evitabili, ma evitabili con meccanismi che
sono di impiego comune da una decina d'anni (tempi che in questo
settore, si sa, fanno la differenza piu' o meno come tra il cercopiteco
e l'Homo Sapiens).

Forse e' opportuno riflettere sul fatto che l'Informatica non e' piu'
soltanto il regno dell'innovazione, ma anche una disciplina con una sua
storia, forse breve ma da conoscere comunque (almeno tra gli addetti ai
lavori) perche' fatta di scelte, anche ma non soltanto sul fronte
sicurezza.


un saluto
Marcello Magnifico
Stefano Zanero
2010-06-21 12:40:13 UTC
Permalink
Post by Marcello Magnifico
cio' e' obbligatorio per la comunicazione di atti ufficiali. Se, pero',
qualcuno lo fa senza essere il legittimo mittente o un soggetto che
opera in nome e per conto suo, probabilmente incorre nel reato di
"falso" o in una sua qualche variante.
E nel mondo digitale cio' e' diverso come... ?
Post by Marcello Magnifico
Da un punto di vista tecnico, cio' e' molto brutto, poiche' si vorrebbe
che la tecnica fosse/creasse IL vincolo per cio' che si puo' o non si
puo' "davvero" fare.
Non vedo il motivo. La tecnologia della PEC vuole sostituire UNO
specifico strumento e risolvere UNO specifico problema. Quello
dell'autenticita' e' un ALTRO problema e gia' esiste un ALTRO strumento,
tecnico e normativo, per risolverlo (la firma qualificata).
Post by Marcello Magnifico
Cio' non legittima comunque, a mio avviso, un database di password in
chiaro
Ovviamente. Questo l'abbiamo detto da principio.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
ascii
2010-06-17 17:59:14 UTC
Permalink
Post by r***@serge.it
Lato utente non cambia quasi nulla.
Poi e' chiaro che se io come risposta alla domanda segreta in ogni sito
uso "XX4c%vR&&£" indipendentemente
dal fatto che mi chiedano il nome del cane o del gatto o di mia mamma da
nubile, tutti i discorsi sulla "probabilita' di conoscere la risposta"
vanno a farsi friggere.
Se utilizzi la stessa risposta segreta (sara' memorizzata in chiaro o
sotto forma di hash? gaping loophole :D; se la riutilizzi su piu'
servizi quanti avranno scelto il primo metodo e quanti il secondo?) per
tutti i servizi, inclusa la casella di posta, aumenti di molto la
possibilita' di rendere felice il tuo attaccante.

Meglio variare anche la risposta alla domanda segreta, che, imho, e'
nelle intenzioni di chi l'ha "inventata", un modo per attingere ad
informazioni eterogenee tra loro e relativamente facili da ricordare
da parte dell'utente.

Ciao,
Francesco `ascii` Ongaro
http://www.ush.it/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
giobbe
2010-06-12 19:22:51 UTC
Permalink
Post by chopinx04
Allora, dopo tutto questo, mi chiedo: e' proponibile per questo tipo
di servizi obbligare i clienti ad avere una chiave asimmetrica di
qualche tipo cosi' che l'email contenente la password resettata o il
link o qualsiasi altra soluzione possa essere cryptata lato server con
la chiave pubblica del cliente? O secondo voi una soluzione del genere
e' troppo sofisticata?
Secondo me a senso proprio per il fatto che la PEC ha valore legale.
Esistono varie possibili soluzioni.
Conoscendo l'implementazione della PEC di un paio di gestori,
secondo me il "workflow" con il miglior rapporto sicurezza/prezzo e':

self-reset con "domanda" e "risposta" scelte dall'utente,
notifica della nuova password via mail,
obbligo di cambio password al successivo login

Ma dato che i tempi di roll-out in produzione di una TELCO italiana
sono "bibilici"... meglio non sperarci :)


La soluzione chiave asimmetrica non e' compatibile con i tempi di
business che diventerebbero troppo lunghi nel caso in cui l'utente
perde il dispositivo contente la chiave. Dato che il sistema ha valore
legale, il gestore dovrebbe tener conto delle implicazioni legali di
eventuali ritardi nella consegna dei dispositivi e/o delle chiavi
sostitutive.

Quanto al fatto che le pass non sono codificate in one-way, lo trovo
assolutamente vergognoso.
Da quanto mi risulta inoltre CNIPA esegue delle verifiche a livello
funzionale, ma non manda ispettori dal provider a controllare se i
repository sono effettivamente cifrati, e con quale algoritmo.

Ciao,
Alessandro
Claudio Telmon
2010-06-13 11:51:49 UTC
Permalink
Post by chopinx04
[....]
stavo leggendo il thread e quindi mi e' sorto il dubbio: ma allora
cosa dovrebbe fare Aruba o qualsiasi ISP che fornisce servizi PEC?
Questa, infatti, è la domanda interessante :) Qualsiasi meccanismo di
autenticazione, e quindi anche qualsiasi meccanismo di scambio di
credenziali, richiede per l'inizializzazione (o la ricontrattazione) un
canale "sicuro": quando questo canale non c'è, la sicurezza del
meccanismo viene degradata a quella del canale utilizzato. Ad esempio,
la sicurezza di un meccanismo di autenticazione basato su certificati
dipende prima di tutto dal canale con cui ti arriva il certificato della
CA, e da quello con cui ti identifichi alla RA per consegnare la tua
chiave pubblica (e quindi, risalendo ancora, da quello con cui ti
identifichi all'anagrafe per ottenere la carta d'identità).

Nel caso della PEC, cos'è previsto dalle specifiche?
E se vogliamo essere ancora più tignosi, qual'è la valutazione del
rischio che ha considerato accettabili alcuni meccanismi e non altri?

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
giobbe
2010-06-19 14:45:00 UTC
Permalink
Questa, infatti, ? la domanda interessante :) Qualsiasi meccanismo di
autenticazione, e quindi anche qualsiasi meccanismo di scambio di
credenziali, richiede per l'inizializzazione (o la ricontrattazione) un
canale "sicuro": quando questo canale non c'?, la sicurezza del
meccanismo viene degradata a quella del canale utilizzato. Ad esempio,
la sicurezza di un meccanismo di autenticazione basato su certificati
dipende prima di tutto dal canale con cui ti arriva il certificato della
CA, e da quello con cui ti identifichi alla RA per consegnare la tua
chiave pubblica (e quindi, risalendo ancora, da quello con cui ti
identifichi all'anagrafe per ottenere la carta d'identit?).
Nel caso della PEC, cos'? previsto dalle specifiche?
E se vogliamo essere ancora pi? tignosi, qual'? la valutazione del
rischio che ha considerato accettabili alcuni meccanismi e non altri?
Le specifiche sono qui: http://www.cnipa.gov.it/site/_files/Pec-def.pdf

"La chiave privata e le operazioni di firma devono essere gestite
utilizzando un dispositivo hardware
dedicato, in grado di garantirne la sicurezza in conformit? a criteri
riconosciuti in ambito europeo o
internazionale. "

Molto aleatorio... nella pratica, e' previsto che la generazione della
richiesta dei certificati PKCS10 avvenga su un dispositivo conforme
allo standard FIPS, se non sbaglio almeno di livello 140-2.

"Security Level 2 improves upon the physical security mechanisms of a
Security Level 1 cryptographic module by requiring features that show
evidence of tampering, including tamper-evident coatings or seals that
must be broken to attain physical access to the plaintext
cryptographic keys and critical security parameters (CSPs) within the
module, or pick-resistant locks on covers or doors to protect against
unauthorized physical access."

Stendo un velo pietoso sul riconoscimento di questa specifica in
italia, onestamente non sono neanche molto aggiornato sullo stato
attuale.

Ad ogni modo ritengo la PEC un tentativo di digitalizzare la
burocrazia, e non di digitalizzare le comunicazioni con la pubblica
amministrazione, tentativo che ritengo eseguito in modo autoritativo e
gerarchico nel senso tecnico del termine (x.509 per intenderci).

Mi spiego meglio: Quando vi viene rilasciata la carta d'identita' a 16
anni, dovete presentarvi con almeno 1-2 parenti per farvi riconoscere
davanti all'ufficiale d'anagrafe, si tratta quindi un "circle of
trust". Da quel momento in poi, tutte le comunicazioni con la pubblica
amministrazione partono dal presupposto che c'e' stato un "circle-of-
trust iniziale"
che ha consentito il "provisioning" del vostro "account" nel "sistema".

Perche' non posso andare al comune con la carta d'identit? alla mano e
farmi firmare la mia chiave pubblica dall'ufficiale d'anagrafe, per
poi usarla per fare le mie comunicazioni con pubblica amministrazione
e privati??

Pensateci, tutto quello che serve, e' la sicurezza dell'identita' dei
corrispondenti, e del contenuto del messaggio.... cosa realizzabile
con semplice un "circle-of-trust".

L'unica cosa che fa in piu' la PEC... e' assicurarsi che il messaggio
sia arrivato nella INBOX del destinatario, che viene de facto
equiparato a una "residenza digitale".

Cosa succede se non aprite la mailbox? Il messaggio risulta comunque
consegnato, di conseguenza e' colpa vostra se non lo aprite.

Quando invece vi arriva una raccomandata a casa e non ci siete, il
postino non la lascia nella cassetta delle lettere... vi lascia una
notifica, e dovete andarvela a prendere alle poste, perche' qualcuno
deve accertarsi che voi o un vostro delegato siete consapevoli del
fatto che vi e' stata inviata una raccomandata.

Si apre la strada alle notifiche di PEC via teledrin?


lol
ciao
- Claudio
--
Claudio Telmon
http://www.telmon.org
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Alessandro Feltrin
2010-06-23 21:05:51 UTC
Permalink
Ad ogni modo ritengo la PEC un tentativo di digitalizzare la burocrazia,
e non di digitalizzare le comunicazioni con la pubblica amministrazione,
tentativo che ritengo eseguito in modo autoritativo e gerarchico nel
senso tecnico del termine (x.509 per intenderci).
La PEC potrebbe essere una buona idea ma solo se l'avessero introdotta
senza "obblighi" particolari.
Quindi giusto per rendere un pò più moderna la vecchia Raccomandata con
ricevuta di ritorno.
Per tutte le altre comunicazioni sarebbe stato sufficiente lavorare un
pò di più sugli obblighi che i provider di servizi di e-mail dovrebbero
avere in termini di garanzia del timestamp.
Per il resto, l'identità digitale siamo già capaci di garantirla anche
meglio rispetto alla PEC, con l'uso dei certificati X-509, con o senza
l'utilizzo di SmartCard.
Pensateci, tutto quello che serve, e' la sicurezza dell'identita' dei
corrispondenti, e del contenuto del messaggio.... cosa realizzabile con
semplice un "circle-of-trust".
L'unica cosa che fa in piu' la PEC... e' assicurarsi che il messaggio
sia arrivato nella INBOX del destinatario, che viene de facto equiparato
a una "residenza digitale".
Cosa succede se non aprite la mailbox? Il messaggio risulta comunque
consegnato, di conseguenza e' colpa vostra se non lo aprite.
E cosa succede se ho la mailbox piena perchè i 100 MB o il GB che mi
hanno dato non bastano più? E' facile lasciare la rsponsabilità
all'end-user. A molte persone la PEC è stata fornita, ma molti non
l'hanno mai utilizzata. Potrebbero avere centinaia di messaggi non letti
nella loro casella. E per la legge è sufficiente che il Server cui si
appoggia il destinatario abbia fatto ritornare la ricevuta di consegna.
Non importa se il destinatario ha letto o no la mail.
Un po diverso, rispetto alla posta convenzionale.
Quando invece vi arriva una raccomandata a casa e non ci siete, il
postino non la lascia nella cassetta delle lettere... vi lascia una
notifica, e dovete andarvela a prendere alle poste, perche' qualcuno
deve accertarsi che voi o un vostro delegato siete consapevoli del fatto
che vi e' stata inviata una raccomandata.
Si apre la strada alle notifiche di PEC via teledrin?
O via SMS ... Che paura ragazzi ...

Alessandro Feltrin
Claudio Telmon
2010-06-28 07:17:08 UTC
Permalink
Post by Alessandro Feltrin
Per tutte le altre comunicazioni sarebbe stato sufficiente lavorare un
pò di più sugli obblighi che i provider di servizi di e-mail dovrebbero
avere in termini di garanzia del timestamp.
Non c'è solo la garanzia del timestamp: c'è la garanzia di consegna e la
tracciabilità, tutte cose che nella raccomandata e nella PEC ci sono.
Inoltre, la legge italiana può intervenire solo su fornitori italiani.
Per esempio, supponiamo che tu voglia mandare una notifica con tempi
certi a qualcuno. Quel qualcuno ha una casella presso un provider
italiano, per raggiungere il quale i messaggi passano da un server
all'estero che, guarda caso, si perde sempre i messaggi per quel
provider (che le sue caselle, ***@paradisofiscale, se le fa pagare
bene ;) ) Cosa fai? E se il messaggio si perde e basta, senza sapere
dove? La legge prevede degli obblighi e dei diritti quando si parla di
notifiche. E poi, di nuovo, dov'è la prova di consegna se lavori solo
sui timestamp? Nei log del provider?

Alla fine, se al posto di un generico "lavorare un pò di più sugli
obblighi che i provider di servizi di e-mail dovrebbero avere" entri nel
merito dei diversi problemi e tieni conto delle funzionalità e garanzie
che ti servono, non arrivi lontano dalla PEC. Ripeto, al di là di
affermazioni generiche, alternative alla PEC che diano veramente quel
tipo di servizio non ne ho ancora viste.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco d'Itri
2010-06-28 09:27:45 UTC
Permalink
Post by Claudio Telmon
Per esempio, supponiamo che tu voglia mandare una notifica con tempi
certi a qualcuno. Quel qualcuno ha una casella presso un provider
italiano, per raggiungere il quale i messaggi passano da un server
all'estero che, guarda caso, si perde sempre i messaggi per quel
bene ;) ) Cosa fai? E se il messaggio si perde e basta, senza sapere
Implementi un meccanismo di ricevute end-to-end come è giusto che sia
invece che inventare un nuovo protocollo. Se si perde ti comporti come
ti comporti quando si perde un messaggio: chiedi al tuo provider di
dire cosa ne ha fatto, usi il telefono, ecc.
Non equivale a una raccomandata, ma risolve il 99% dei casi (quelli in
cui il destinatario non ha interesse a fare finta di non avere ricevuto
il messaggio).

(Immagino che non sia un caso che la PEC sia stata inventata in un posto
pieno di orfani di X.400...)
--
ciao,
Marco
Claudio Telmon
2010-06-28 18:53:38 UTC
Permalink
Post by Marco d'Itri
Implementi un meccanismo di ricevute end-to-end come è giusto che sia
invece che inventare un nuovo protocollo.
Sarei interessato a sapere di più di questo protocollo. Però deve
risolvere almeno i problemi di notifica da/a PA, altrimenti non vale ;)
Post by Marco d'Itri
Se si perde ti comporti come
ti comporti quando si perde un messaggio: chiedi al tuo provider di
dire cosa ne ha fatto, usi il telefono, ecc.
Non equivale a una raccomandata, ma risolve il 99% dei casi (quelli in
cui il destinatario non ha interesse a fare finta di non avere ricevuto
il messaggio).
Immagino che la percentuale sia arbitraria... quali sono i 99% dei casi
in cui ti serve la raccomandata ma non si pone il problema che il
destinatario non sia disposto a confermare la ricevuta?
Diciamo comunque allora che la PEC serve per risolvere l'1% dei casi,
che almeno nel caso dei rapporti con la PA secondo me sono una
percentuale più alta. Mi stai dicendo che tu saresti disposto a mandare,
che so, una domanda di ammissione a un concorso pubblico, che deve
arrivare entro un dato giorno, fidandoti di un meccanismo end-to-end in
cui se la domanda non arriva, o la PA che la riceve non ti conferma la
ricezione, "chiedi al tuo provider di dire cosa ne ha fatto, usi il
telefono, ecc."?

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-30 14:33:35 UTC
Permalink
Post by Marco d'Itri
Non equivale a una raccomandata, ma risolve il 99% dei casi (quelli in
cui il destinatario non ha interesse a fare finta di non avere ricevuto
il messaggio).
Dal momento che la raccomandata con ricevuta e la PEC risolvono
ESATTAMENTE il problema di creare una ricevuta OPPONIBILE A TERZI,
ovvero il problema di quando il destinatario ha tutto l'interesse di
fare finta di non aver ricevuto nulla, la soluzione che proponi risolve
un altro problema. O meglio, un non-problema, legalmente.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-27 19:43:55 UTC
Permalink
Post by Alessandro Feltrin
La PEC potrebbe essere una buona idea ma solo se l'avessero introdotta
senza "obblighi" particolari.
L'unico obbligo e' per i professionisti e le imprese, non per i cittadini.
Post by Alessandro Feltrin
Quindi giusto per rendere un pò più moderna la vecchia Raccomandata con
ricevuta di ritorno.
Esattamente quello che e'.
Post by Alessandro Feltrin
Per tutte le altre comunicazioni sarebbe stato sufficiente lavorare un
pò di più sugli obblighi che i provider di servizi di e-mail dovrebbero
avere in termini di garanzia del timestamp.
Questa frase e' priva di senso, atteso che le "e-mail" non sono neppure
equivalenti ad un testo scritto. Figuriamoci a chi puo' importare una
garanzia opponibile a terzi sull'ora e la data.
Post by Alessandro Feltrin
Per il resto, l'identità digitale siamo già capaci di garantirla anche
meglio rispetto alla PEC, con l'uso dei certificati X-509, con o senza
l'utilizzo di SmartCard.
Aridagli. La PEC non garantisce l'identita' di nessuno!

La PEC garantisce la consegna nella disponibilita' del destinatario.

Santa pazienza, e' cosi' difficile?
Post by Alessandro Feltrin
E cosa succede se ho la mailbox piena
Che il messaggio rimbalza e il mittente sa che NON è stato consegnato.

La smettiamo di inventare problemi che non esistono? Quelli che esistono
sono già abbastanza.
Post by Alessandro Feltrin
all'end-user. A molte persone la PEC è stata fornita, ma molti non
l'hanno mai utilizzata.
A chi, per esempio?

Vedi sopra sulla creazione di problemi inesistenti.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
Stefano Zanero
2010-06-23 21:20:47 UTC
Permalink
Giuro che ci provo per l'ultima volta...
Post by giobbe
Le specifiche sono qui: http://www.cnipa.gov.it/site/_files/Pec-def.pdf
"La chiave privata e le operazioni di firma devono essere gestite
utilizzando un dispositivo hardware
dedicato, in grado di garantirne la sicurezza in conformit? a criteri
riconosciuti in ambito europeo o
internazionale. "
Si parla delle chiavi dei gestori, ovviamente, visto che gli utenti non
ne hanno bisogno (perche' la PEC, come avro' ripetuto un milione di
volte, non si occupa di garantire l'autenticita'...)
Post by giobbe
Stendo un velo pietoso sul riconoscimento di questa specifica in italia,
Controesempi, prego?
Post by giobbe
Perche' non posso andare al comune con la carta d'identit? alla mano e
farmi firmare la mia chiave pubblica dall'ufficiale d'anagrafe, per poi
usarla per fare le mie comunicazioni con pubblica amministrazione e
privati??
1) perche' la PEC non risolve QUESTO problema, ne risolve UN ALTRO,
mannaggia

2) questo e' ESATTAMENTE quello che succede con la firma digitale (con
l'unica differenza che al posto dell'ufficiale dell'anagrafe ti trovi il
dipendente di un certificatore)
Post by giobbe
L'unica cosa che fa in piu' la PEC... e' assicurarsi che il messaggio
sia arrivato nella INBOX del destinatario,
Non e' la cosa che fa IN PIU'

E' la cosa che FA

L'altra NON - LA - FA !!!!!!!!!!!!!!!!!!1
Post by giobbe
Cosa succede se non aprite la mailbox? Il messaggio risulta comunque
consegnato, di conseguenza e' colpa vostra se non lo aprite.
Esatto.
Post by giobbe
Quando invece vi arriva una raccomandata a casa e non ci siete
E ale', per la centesima volta siamo TORNATI a ribadire questa
differenza. Certo che e' diversa. Quella e' la raccomandata e questa e'
la PEC.

Hanno lo stesso effetto riguardo all'opponibilita', mica sta scritto da
nessuna parte che siano la stessa identica cosa. Fatevene una ragione (e
due...)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Ermini
2010-06-10 16:47:41 UTC
Permalink
2010/6/9 Dario Fiumicello:
[...]
Post by Dario Fiumicello
Personalmente mi sembra una grossa falla di sicurezza considerando che
- Se la password mi arriva in chiaro significa che sui loro DB è in
 chiaro, e questo già non è bene
- La password arriva su una casella di posta classica, senza nessuna
 cifratura!
Che ne pensate?
Sono d'accordo, e capisco perché lo fanno - per loro è più facile fare
così che implementare un meccanismo di password self reset,
ovviamente.

Comunque persino ISACA fa lo stesso, il che è tutto dire... LOL :-)


Cordiali saluti
--
Marco Ermini
***@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Gabriele Zanoni
2010-06-10 08:10:22 UTC
Permalink
Post by Dario Fiumicello
Ciao a tutti
Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.
Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!
Se la password che ti hanno rimandato in chiaro Ú la stessa password che hai
messo in fase di iscrizione tu stesso... sì Ú un bug.

saluti,

Gabriele
Dario Fiumicello - Antek
2010-06-11 13:44:57 UTC
Permalink
Il giorno Thu, 10 Jun 2010 10:10:22 +0200
Post by Gabriele Zanoni
Post by Dario Fiumicello
Ciao a tutti
Ho una casella PEC fornita dall'ordine degli ingegneri della mia
città e gestita da aruba. L'altro giorno volevo entrare ma non
ricordavo la password.
Clicco sul link del remainder e mi viene spedita nella mia casella
di posta elettronica NON CERTIFICATA la password per accedere alla
PEC IN CHIARO!
Se la password che ti hanno rimandato in chiaro Ú la stessa password
che hai messo in fase di iscrizione tu stesso... sì Ú un bug.
E' proprio la stessa.
--
Dario Fiumicello - Antek S.r.l.
+3902890380 93 - Porto Mantovano (MN) Italy
+3902890380 43 - Pace del Mela (ME) Italy
Alessio Cecchi
2010-06-10 10:46:47 UTC
Permalink
Post by Dario Fiumicello
Ciao a tutti
Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.
Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!
Personalmente mi sembra una grossa falla di sicurezza considerando che
- Se la password mi arriva in chiaro significa che sui loro DB Ú in
chiaro, e questo già non Ú bene
- La password arriva su una casella di posta classica, senza nessuna
cifratura!
Che ne pensate?
Penso che Ú, quasi, la norma conservare nei propri DB le password in
chiaro specialmente per la posta elettronica, almeno nell'ambito dei
medi/grossi ISP. Non Ú invece la norma ne tanto meno elegante farlo
sapere in giro.

Le password i chiaro sono utili per attività di help-desk, fondamentali
in caso di migrazioni o altre attività straordinarie. Però un conto Ú
mantenerle per solo questo tipo di attività ed n conto Ú inviarle in
chiaro, specie per la PEC.

Noi quando installiamo un mail server per questo genere di contesti
facciamo presente al cliente che Ú possibile mantenere in chiaro una
copia della password, se lui lo ritiene opportuno ci specifica che vuole
avere anche le password in chiaro. Poi a livello di sistema questa
password in chiaro non Ú mai utilizzati dai software che fanno sempre
riferimento ad un hash per il confronto delle password fornite
dall'utente, si tratta solo di un campo extra nel DB. Qualcuno le vuole,
altri no. Noi facciamo presente i pro ed i contro poi decidano loro.

Certo non Ú bello sapere che nei DB dei grossi ISP ci sono le nostre
password anche in chiaro.

Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati
sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre
password in chiaro.

Ciao
--
Alessio Cecchi is:
@ ILS -> http://www.linux.it/~alessice/
on LinkedIn -> http://www.linkedin.com/in/alessice
Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/
@ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it
@ LOLUG -> Socio http://www.lolug.net
Elettrico
2010-06-12 21:44:41 UTC
Permalink
Post by Alessio Cecchi
Penso che Ú, quasi, la norma conservare nei propri DB le password in
chiaro specialmente per la posta elettronica, almeno nell'ambito dei
medi/grossi ISP. Non Ú invece la norma ne tanto meno elegante farlo
sapere in giro.
a me questa scusami ma sembra una bestialità. io non tengo nessuna
password in chiaro dei miei clienti, e non ci sono operazioni che io non
possa fare. per quali operazioni di help-desk e migrazione necessiti
della password in chiaro??
Alessio Cecchi
2010-06-14 14:45:52 UTC
Permalink
Post by Elettrico
Post by Alessio Cecchi
Penso che Ú, quasi, la norma conservare nei propri DB le password in
chiaro specialmente per la posta elettronica, almeno nell'ambito dei
medi/grossi ISP. Non Ú invece la norma ne tanto meno elegante farlo
sapere in giro.
a me questa scusami ma sembra una bestialità. io non tengo nessuna
password in chiaro dei miei clienti, e non ci sono operazioni che io non
possa fare. per quali operazioni di help-desk e migrazione necessiti
della password in chiaro??
Non ho detto che sia corretto, ho detto quello che succede in giro, io
personalmente sulle mie personali installazioni non lascio nessuna
password in chiaro, e ci mancherebbe altro.

Volevo solo dire che richieste da parte dei gestori di mail server di
avere le password in chiaro archiviate da qualche parte ci sono e questa
discussione dimostra la fondatezza della mia affermazione.

Ciao
--
Alessio Cecchi is:
@ ILS -> http://www.linux.it/~alessice/
on LinkedIn -> http://www.linkedin.com/in/alessice
Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/
@ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it
@ LOLUG -> Socio http://www.lolug.net
Flavio Visentin
2010-06-13 12:55:33 UTC
Permalink
Post by Alessio Cecchi
Penso che Ú, quasi, la norma conservare nei propri DB le password in
chiaro specialmente per la posta elettronica, almeno nell'ambito dei
medi/grossi ISP. Non Ú invece la norma ne tanto meno elegante farlo
sapere in giro.
Ma figuriamoci. Uno dei casi dove di norma non lo fa nessuno Ú proprio
quello della posta elettronica dato che Ú totalmente inutile. AFAIK nessuno
dei grossi mail SP lo fa.
Post by Alessio Cecchi
Le password i chiaro sono utili per attività di help-desk,
Quali? Non mi sovviene nemmeno un singolo caso in cui sia utile la password
in chiaro.
Post by Alessio Cecchi
fondamentali in caso di migrazioni
Ho fatto decine di migrazioni fra sistemi di posta diversi e non mi Ú *MAI*
servito conoscere le password degli utenti. O sono io un supersistemista
(dubito) o non serve a nulla conoscerle.
Post by Alessio Cecchi
o altre attività straordinarie.
Per esempio?
Post by Alessio Cecchi
Però un conto Ú
mantenerle per solo questo tipo di attività ed n conto Ú inviarle in
chiaro, specie per la PEC.
E' la stessa cosa. Solo uno sviuluppatore cane si sogna di memorizzare
password di accesso a servizi in chiaro, perché non servono e perché sono
pericolose.
Post by Alessio Cecchi
Noi quando installiamo un mail server per questo genere di contesti
facciamo presente al cliente che Ú possibile mantenere in chiaro una
copia della password, se lui lo ritiene opportuno ci specifica che vuole
avere anche le password in chiaro.
Male. State rendendo un sistema vulnerabile e sicuramente siete al di fuori
di ogni criterio di gestione della sicurezza. C'Ú *SOLO* un caso in cui ciò
sia utile, ed nel caso in cui si stia facendo il debugging
dell'applicazione, in fase di sviluppo. Mai in produzione.
Post by Alessio Cecchi
Poi a livello di sistema questa
password in chiaro non Ú mai utilizzati dai software che fanno sempre
riferimento ad un hash per il confronto delle password fornite
dall'utente, si tratta solo di un campo extra nel DB.
Un bellissimo campo extra che in caso di bug di sicurezza, p.es. una bella
sql injection, svela all'attaccante TUTTE le password in chiaro e oltre a
questo probabilmente anche i criteri di scelta delle password dei vari utenti.
Post by Alessio Cecchi
Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati
sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre
password in chiaro.
Non deve farlo e punto.

- --
Flavio Visentin
GPG Key: http://www.zipman.it/gpgkey.asc

There are only 10 types of people in this world:
those who understand binary, and those who don't.
Alessio Cecchi
2010-06-14 15:00:16 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Alessio Cecchi
Penso che Ú, quasi, la norma conservare nei propri DB le password in
chiaro specialmente per la posta elettronica, almeno nell'ambito dei
medi/grossi ISP. Non Ú invece la norma ne tanto meno elegante farlo
sapere in giro.
Ma figuriamoci. Uno dei casi dove di norma non lo fa nessuno Ú proprio
quello della posta elettronica dato che Ú totalmente inutile. AFAIK nessuno
dei grossi mail SP lo fa.
Questa discussione dimostra che viene fatto ed anche da un grosso ISP.
Poi magari non viene fatto sapere in giro ma so per certo che Ú prassi
comune. Poi quanto sia diffuso non saprai ma viene fatto.
Post by Alessio Cecchi
Le password i chiaro sono utili per attività di help-desk,
Quali? Non mi sovviene nemmeno un singolo caso in cui sia utile la password
in chiaro.
Post by Alessio Cecchi
fondamentali in caso di migrazioni
Ho fatto decine di migrazioni fra sistemi di posta diversi e non mi Ú *MAI*
servito conoscere le password degli utenti. O sono io un supersistemista
(dubito) o non serve a nulla conoscerle.
Ok, mi rimangio il fondamentale, diciamo che Ú utile, soprattutto
passando fra sistemi in cui gli hash di codifica delle password sono
diversi e non compatibili fra di loro.
Post by Alessio Cecchi
o altre attività straordinarie.
Per esempio?
Post by Alessio Cecchi
Però un conto Ú
mantenerle per solo questo tipo di attività ed n conto Ú inviarle in
chiaro, specie per la PEC.
E' la stessa cosa. Solo uno sviuluppatore cane si sogna di memorizzare
password di accesso a servizi in chiaro, perché non servono e perché sono
pericolose.
Come dici dopo lo sviluppatore in fase di debug può ritenere utile
questa funzione e magari, invece di metterla e muoverla ogni volta la
rende attivabile mediante un opzione.
Post by Alessio Cecchi
Noi quando installiamo un mail server per questo genere di contesti
facciamo presente al cliente che Ú possibile mantenere in chiaro una
copia della password, se lui lo ritiene opportuno ci specifica che vuole
avere anche le password in chiaro.
Male. State rendendo un sistema vulnerabile e sicuramente siete al di fuori
di ogni criterio di gestione della sicurezza. C'Ú *SOLO* un caso in cui ciò
sia utile, ed nel caso in cui si stia facendo il debugging
dell'applicazione, in fase di sviluppo. Mai in produzione.
E' la stessa coda che noi diciamo al cliente per disincentivare questa
pratica. Molti chiedono questa possibilità, molto rinunciano, qualcuno
la vuole ugualmente.
Post by Alessio Cecchi
Poi a livello di sistema questa
password in chiaro non Ú mai utilizzati dai software che fanno sempre
riferimento ad un hash per il confronto delle password fornite
dall'utente, si tratta solo di un campo extra nel DB.
Un bellissimo campo extra che in caso di bug di sicurezza, p.es. una bella
sql injection, svela all'attaccante TUTTE le password in chiaro e oltre a
questo probabilmente anche i criteri di scelta delle password dei vari utenti.
Giusto, si potrebbe mettere in un DB separato con privilegi diversi,
grazie per il suggerimento.
Post by Alessio Cecchi
Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati
sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre
password in chiaro.
Non deve farlo e punto.
Mi ma di fatto accade.

Ciao
--
Alessio Cecchi is:
@ ILS -> http://www.linux.it/~alessice/
on LinkedIn -> http://www.linkedin.com/in/alessice
Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/
@ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it
@ LOLUG -> Socio http://www.lolug.net
Elettrico
2010-06-15 15:55:01 UTC
Permalink
Post by Alessio Cecchi
Questa discussione dimostra che viene fatto ed anche da un grosso ISP.
Poi magari non viene fatto sapere in giro ma so per certo che Ú prassi
comune. Poi quanto sia diffuso non saprai ma viene fatto.
allora se ci dici quale isp così tutti smettiamo di usarlo ci fai un
favore...

cmq non sappiamo se il fatto che la password sia spedita in chiaro vuol
dire che sia conservata in chiaro, sappiamo sicuramente che Ú possibile
estrarla in qualche maniera. questo non vuol dire che vada bene, eh.
Post by Alessio Cecchi
Ok, mi rimangio il fondamentale, diciamo che Ú utile, soprattutto
passando fra sistemi in cui gli hash di codifica delle password sono
diversi e non compatibili fra di loro.
non capisco bene: ad esempio?
Post by Alessio Cecchi
Come dici dopo lo sviluppatore in fase di debug può ritenere utile
questa funzione e magari, invece di metterla e muoverla ogni volta la
rende attivabile mediante un opzione.
anche io quando sviluppo ho un foglio excel da qualche parte dove ci
sono tre o quattro utenti con le loro password. questa però Ú un'altra cosa.
Post by Alessio Cecchi
E' la stessa coda che noi diciamo al cliente per disincentivare questa
pratica. Molti chiedono questa possibilità, molto rinunciano, qualcuno
la vuole ugualmente.
ma Ú molto più semplice la questione: la password in chiaro in un db non
ci dovrebbe essere, al di là delle richieste del cliente. se gli piace
la password in chiaro la può scrivere su un post-it e attaccarla sul
monitor.
Post by Alessio Cecchi
Giusto, si potrebbe mettere in un DB separato con privilegi diversi,
grazie per il suggerimento.
ah, ma quindi siamo AVANTI: le password sono nello stesso db, magari
sono anche nella stessa tabella?? ma a che livello siamo?
Post by Alessio Cecchi
Mi ma di fatto accade.
eh, complimenti :)
William Maddler
2010-06-16 10:23:07 UTC
Permalink
Post by Alessio Cecchi
Giusto, si potrebbe mettere in un DB separato con privilegi diversi,
grazie per il suggerimento.
Dal punto di vista della sicurezza dei dati le password memorizzate in
chiaro sono una cappellata. Sara` comodo quanto vuoi, ma e` una cappellata.

In caso di compromissione del DB esponi TUTTI i tuoi utenti a rischi
potenzialmente considerevoli. Se poi ti va bene accettare il rischio, amen.

William
Gengis Dave
2010-06-17 13:54:21 UTC
Permalink
Post by William Maddler
Post by Alessio Cecchi
Giusto, si potrebbe mettere in un DB separato con privilegi diversi,
grazie per il suggerimento.
Dal punto di vista della sicurezza dei dati le password memorizzate in
chiaro sono una cappellata. Sara` comodo quanto vuoi, ma e` una cappellata.
In caso di compromissione del DB esponi TUTTI i tuoi utenti a rischi
potenzialmente considerevoli. Se poi ti va bene accettare il rischio, amen.
La politica di gestione delle password in chiaro e' estesa, da Aruba, a tutti
i suoi account, compresi quelli per accedere agli spazi web.

La procedura di recupero della password e' automatica e richiede pochi dati
personali, in genere il solo nome dell'account (email con nome numerico
***@aruba.it). Nel caso l'account sia associato ad un servizio, spazio
web, database che sia, viene chiesto il CF o la P.IVA dell'intestatario del
dominio.

I dati (username e password), ovviamente, vengono inviati in chiaro alla mail
di riferimento, con gli scenari che sono gia' stati ampiamente discussi.

Ciao
Dave
alexagosto62
2010-06-16 13:17:22 UTC
Permalink
Post by Flavio Visentin
Post by Alessio Cecchi
Noi quando installiamo un mail server per questo genere di contesti
facciamo presente al cliente che Ú possibile mantenere in chiaro una
copia della password, se lui lo ritiene opportuno ci specifica che vuole
avere anche le password in chiaro.
Male. State rendendo un sistema vulnerabile e sicuramente siete al di fuori
di ogni criterio di gestione della sicurezza. C'è *SOLO* un caso in cui ciò
sia utile, ed nel caso in cui si stia facendo il debugging
dell'applicazione, in fase di sviluppo. Mai in produzione.
Vero !! In assenza di sistemi più efficaci della password è bene che gli
utenti siano responsabilizzati sulla gestione delle stesse.
Soprattutto, al di la della complessita' dekka password occorre che, per
policy, questa venga cambiata con una certa periodicita' (che so, 60
giorni ad esempio). Le tecniche per costruire delle password complesse
ci sono. Su questo credo manchi formazione.
E' la stessa coda che noi diciamo al cliente per disincentivare questa pratica. Molti chiedono questa possibilità , molto rinunciano, qualcuno la vuole ugualmente.
Post by Flavio Visentin
Post by Alessio Cecchi
Poi a livello di sistema questa
password in chiaro non Ú mai utilizzati dai software che fanno sempre
riferimento ad un hash per il confronto delle password fornite
dall'utente, si tratta solo di un campo extra nel DB.
Un bellissimo campo extra che in caso di bug di sicurezza, p.es. una bella
sql injection, svela all'attaccante TUTTE le password in chiaro e oltre a
questo probabilmente anche i criteri di scelta delle password dei vari utenti.
Giusto, si potrebbe mettere in un DB separato con privilegi diversi, grazie per il suggerimento.
Post by Flavio Visentin
Post by Alessio Cecchi
Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati
sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre
password in chiaro.
Non deve farlo e punto.
Mi ma di fatto accade.
Quello che mi preoccupa e' che stiamo parlando di PEC ... Se e' vero che
le cose dette prima potrebbero essere "accettate" storcendo un po' il
naso su una mailbox di hotmail, di libero o che altro, questo non e'
vero per la PEC. Ci stanno obbligando praticamente a possederne almeno
una per ciascuno. Dico "almeno" perchè oltre a quella di Poste, di ACI e
di INPS ci potrebbe essere l'ordine degli ingegneri che ti obbliga ad
avere la sua PEC, poi l'associazione x che ti fornisce la sua, etc etc.
Alla fine, oltre ad avere un certo numero di caselle "normali" rischiamo
di avere più caselle di PEC.

Comunque io per mitigare il problema dell'autenticità del mittente
propongo di fare piu' uso dei certificati digitali. Infatti essi possono
essere "tranquillamente" abbinati alla PEC, a patto che si disponga di
un client evoluto (thunderbird, outlook, etc etc) e non di una Webmail.
In questo modo, al di la' della password della casella, se voglio
"certificare" meglio l'autenticità del mio messaggio, lo firmo
digitalmente (e me ne fotto del certificato della PEC, che garantisce
solo l'autenticità dei peer).

Alessandro Feltrin
Stefano Zanero
2010-06-17 12:00:13 UTC
Permalink
Post by alexagosto62
vero per la PEC. Ci stanno obbligando praticamente a possederne almeno
una per ciascuno.
No, non e' vero, nessuno e' obbligato a possedere una casella di PEC.
Post by alexagosto62
Dico "almeno" perchè oltre a quella di Poste, di ACI e
di INPS
Che non sono caselle di PEC, ma di CEC (Comunicazione Elettronica
Certificata), utilizzabili solo per il dialogo con la PA da parte del
cittadino.
Post by alexagosto62
ci potrebbe essere l'ordine degli ingegneri che ti obbliga ad
avere la sua PEC, poi l'associazione x che ti fornisce la sua, etc etc.
Nessun ordine (tantomeno il mio) OBBLIGA ad avere una certa casella. Il
professionista e' tenuto ad averne UNA, e a comunicarla al (o agli)
ordini professionali a cui e' iscritto.
Post by alexagosto62
Alla fine, oltre ad avere un certo numero di caselle "normali" rischiamo
di avere più caselle di PEC.
Chi vuole, e se vuole. Che differenza fa?
Post by alexagosto62
Comunque io per mitigare il problema dell'autenticità del mittente
propongo di fare piu' uso dei certificati digitali.
In questo modo, al di la' della password della casella, se voglio
"certificare" meglio l'autenticità del mio messaggio, lo firmo
digitalmente
AAAAAARGH!

Non e' questione di fare PIU' uso o di certificare MEGLIO l'autenticita'.

La PEC non garantisce NULLA sull'autenticita' (i.e. sull'autore) del
messaggio, NON E' FATTA PER QUELLO e da NESSUNA LEGGE NE DISCENDE UN
VALORE LEGALE.

(nota a margine: no, non e' tecnicamente corretto, perche' se una
casella PEC avesse un singolo utente, il contenuto inviato e' firmato
elettronicamente in quanto associato all'autenticazione per l'invio;
tuttavia se NON conoscete la disciplina su firme elettroniche e digitali
e la differenza vi prego di IGNORARE questa nota senno' vi confonderete
ancora di piu' le gia' ben confuse idee)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
William Maddler
2010-06-17 11:56:26 UTC
Permalink
Post by Flavio Visentin
Post by Alessio Cecchi
Noi quando installiamo un mail server per questo genere di contesti
facciamo presente al cliente che Ú possibile mantenere in chiaro una
copia della password, se lui lo ritiene opportuno ci specifica che vuole
avere anche le password in chiaro.
Male. State rendendo un sistema vulnerabile e sicuramente siete al di fuori
di ogni criterio di gestione della sicurezza. C'ᅵ *SOLO* un caso in cui ciò
sia utile, ed nel caso in cui si stia facendo il debugging
dell'applicazione, in fase di sviluppo. Mai in produzione.
Vero !! In assenza di sistemi piᅵ efficaci della password ᅵ bene che gli
utenti siano responsabilizzati sulla gestione delle stesse.
Soprattutto, al di la della complessita' dekka password occorre che, per
policy, questa venga cambiata con una certa periodicita' (che so, 60
giorni ad esempio). Le tecniche per costruire delle password complesse
ci sono. Su questo credo manchi formazione.
Tra l'altro il garante, se la memoria non mi inganna, stabilisce che
l'unica persona a dover conoscere la propria password e` l'utente
stesso. Correggetemi se sbaglio.
E' la stessa coda che noi diciamo al cliente per disincentivare questa pratica. Molti chiedono questa possibilitᅵ , molto rinunciano, qualcuno la vuole ugualmente.
Post by Flavio Visentin
Post by Alessio Cecchi
Poi a livello di sistema questa
password in chiaro non Ú mai utilizzati dai software che fanno sempre
riferimento ad un hash per il confronto delle password fornite
dall'utente, si tratta solo di un campo extra nel DB.
Un bellissimo campo extra che in caso di bug di sicurezza, p.es. una bella
sql injection, svela all'attaccante TUTTE le password in chiaro e oltre a
questo probabilmente anche i criteri di scelta delle password dei vari utenti.
Giusto, si potrebbe mettere in un DB separato con privilegi diversi, grazie per il suggerimento.
Post by Flavio Visentin
Post by Alessio Cecchi
Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati
sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre
password in chiaro.
Non deve farlo e punto.
Mi ma di fatto accade.
Quello che mi preoccupa e' che stiamo parlando di PEC ... Se e' vero che
le cose dette prima potrebbero essere "accettate" storcendo un po' il
naso su una mailbox di hotmail, di libero o che altro, questo non e'
vero per la PEC. Ci stanno obbligando praticamente a possederne almeno
una per ciascuno. Dico "almeno" perchᅵ oltre a quella di Poste, di ACI e
di INPS ci potrebbe essere l'ordine degli ingegneri che ti obbliga ad
avere la sua PEC, poi l'associazione x che ti fornisce la sua, etc etc.
Alla fine, oltre ad avere un certo numero di caselle "normali" rischiamo
di avere piᅵ caselle di PEC.
E questo, a mio modestissimo parere, e` la cazzate principale della PEC
rispetto all'adozione, come ho detto piu` volte, di altri standard e
soluzioni.
Comunque io per mitigare il problema dell'autenticitᅵ del mittente
propongo di fare piu' uso dei certificati digitali. Infatti essi possono
essere "tranquillamente" abbinati alla PEC, a patto che si disponga di
un client evoluto (thunderbird, outlook, etc etc) e non di una Webmail.
Anche in questo caso puoi "banalmente" utilizzare il certificato come
metodo di autenticazione alla webmail.
In questo modo, al di la' della password della casella, se voglio
"certificare" meglio l'autenticitᅵ del mio messaggio, lo firmo
digitalmente (e me ne fotto del certificato della PEC, che garantisce
solo l'autenticitᅵ dei peer).
Verissimo.
Alessandro Feltrin
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-27 19:40:10 UTC
Permalink
Post by William Maddler
Tra l'altro il garante, se la memoria non mi inganna, stabilisce che
l'unica persona a dover conoscere la propria password e` l'utente
stesso. Correggetemi se sbaglio.
Stiamo parlando di incaricato del trattamento di dati personali, che non
c'entra un piffero con l'utente di una mailbox qualsiasi.
Post by William Maddler
E questo, a mio modestissimo parere, e` la cazzate principale della PEC
rispetto all'adozione, come ho detto piu` volte, di altri standard e
soluzioni.
Che nessuno ha ancora indicato, perche' non ci sono standard per inviare
una ricevuta di consegna opponibile a terzi, certificati da una trusted
third party.

E' un problema molto italiano, e la soluzione non poteva che essere
italiana.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
Marco Pandolfi
2010-06-30 12:46:10 UTC
Permalink
Post by Stefano Zanero
E' un problema molto italiano, e la soluzione non poteva che essere
italiana.
infatti vi risulta che all'estero (per le mie esperienze dirette) vi sia
la raccomandata con ricevuta di ritorno?

qui si sta cercando di "informatizzare" proprio la cara e vecchia
raccomandata con ricevuta di ritorno.

con potenziali spazi in più (allego msg firmati digitalmente - firma
qualificata).

pec + allegato firmato digitalmente = r/r per una busta contenente un
foglio con firma autografa.

poi alle poste la raccomandata la può spedire anche mia nonna!

mp
Post by Stefano Zanero
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Ermini
2010-07-07 11:36:10 UTC
Permalink
2010/6/30 Marco Pandolfi:
[...]
infatti vi risulta che all'estero (per le mie esperienze dirette) vi sia la
raccomandata con ricevuta di ritorno?
Assolutamente sì, in qualsiasi paese civilizzato :-)

Negli USA ne hanno quattro tipi se non ricordo male: certified Mail
(dark green form), return receipt (light green form), delivery
confirmation (neon green form) e signature confirmation (neon pink
form).

http://www.usps.com/send/waystosendmail/extraservices/returnreceiptservice.htm

Anche in Germania esiste e si chiama Bestätigungbrief, ed esiste pure
la versione tedesca della PEC:
http://www.deutschepost.de/dpag?tab=1&skin=hi&check=yes&lang=de_DE&xmlFile=1015458


Cordiali saluti
--
Marco Ermini
***@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Alessandro Feltrin
2010-07-07 13:24:28 UTC
Permalink
Post by Marco Ermini
[...]
infatti vi risulta che all'estero (per le mie esperienze dirette) vi sia la
raccomandata con ricevuta di ritorno?
Assolutamente sì, in qualsiasi paese civilizzato :-)
Nel Regno Unito per esempio non esiste. La posta deve funzionare e
basta. Se una comunicazione non arriva è un reato gravissimo. Non c'è
bisogno di un servizio "con ricevuta di ritorno" da affiancare ad un
servizio "senza ricevuta".
Mi sembra che questo potrebbe essere facilmente utilizzato per
giustificare l'inefficienza del servizio postale (tipo, "ma se hai
mandato una comunicazione senza richiedere la ricevuta di ritorno è già
tanto che arrivi").
Post by Marco Ermini
Negli USA ne hanno quattro tipi se non ricordo male: certified Mail
(dark green form), return receipt (light green form), delivery
confirmation (neon green form) e signature confirmation (neon pink
form).
http://www.usps.com/send/waystosendmail/extraservices/returnreceiptservice.htm
Anche in Germania esiste e si chiama Bestätigungbrief, ed esiste pure
http://www.deutschepost.de/dpag?tab=1&skin=hi&check=yes&lang=de_DE&xmlFile=1015458
Che mi pare sia un servizio postale di Deutsche Post. Non un obbligo di
legge (ma su questo potrei sbagliarmi ...).
E comunque non è una buona ragione per sostenere la PEC ...

Un saluto
Alessandro Feltrin
Post by Marco Ermini
Cordiali saluti
Marco Ermini
2010-07-08 17:34:20 UTC
Permalink
Post by Alessandro Feltrin
Post by Marco Ermini
[...]
infatti vi risulta che all'estero (per le mie esperienze dirette) vi sia la
raccomandata con ricevuta di ritorno?
Assolutamente sì, in qualsiasi paese civilizzato :-)
Nel Regno Unito per esempio non esiste. La posta deve funzionare e
basta.
Stai parlando tu di una eccezione clamorosa - la posta in UK è famosa,
dai tempi dei carteggi di Marx ed Engels che si scrivevano al mattino
e si rispondevano il pomeriggio... è anche l'unico (o quasi
probabilmente, che io sappia...) servizio postale che ti consente di
spedire qualsiasi cosa abbia un francobollo attaccato sopra, infatti
c'è gente che si spedisce toast imburrati - ed arrivano :-)

Stai parlando del paese che ha *inventato* in servizio postale e di un
paese particolare, che si *fregia* di fare qualsiasi cosa
diversamente, specialmente quelle che hanno inventato loro. Infatti
hanno pure inventato il football, e continuano ad ignorare che nel
2010 ti serve anche una difesa, se vuoi passare gli ottavi di finale
di un mondiale... :-)


[...]
Post by Alessandro Feltrin
Che mi pare sia un servizio postale di Deutsche Post. Non un obbligo di
legge (ma su questo potrei sbagliarmi ...).
E comunque non è una buona ragione per sostenere la PEC ...
Non ho mai sostenuto il contrario, né ho mai sostenuto la PEC, mi
sembra che mi hai frainteso. (così come ha fatto Claudio Telmon). L'ho
citato soltanto come esempio e curiosità.

È evidente che è diverso, infatti DP certifica l'identità, cosa che la
PEC non fa. Tuttavia, il servizio è tecnicamente simile, per questo
l'ho citato come interessante.

Che non sia richiesto dalla legge, può darsi (non lo so). Che tu possa
usarlo in caso di necessità in tribunale, credo proprio di sì...


Cordiali saluti
--
Marco Ermini
***@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marcello Magnifico
2010-07-08 15:36:01 UTC
Permalink
Scusate se tento un fork del thread, ma ormai sembra abbastanza palese
qualcosa che avrebbe dovuto esserlo dall'inizio, ovvero che le password
in chiaro sono un orrore tecnico. Si sta, infatti, parlando d'altro,
ovvero della validita' della PEC in quanto tale.
Post by Alessandro Feltrin
Post by Marco Ermini
Post by Marco Pandolfi
raccomandata con ricevuta di ritorno?
Assolutamente sì, in qualsiasi paese civilizzato :-)
Nel Regno Unito per esempio non esiste. La posta deve funzionare e
basta. Se una comunicazione non arriva è un reato gravissimo. Non c'è
bisogno di un servizio "con ricevuta di ritorno" da affiancare ad un
servizio "senza ricevuta".
Il confronto mi sembra piu' valido di tanti altri, per una questione di
pure cifre: l'estensione territoriale del Regno Unito e' paragonabile,
per ordine di grandezza, a quella italiana (quella degli Stati Uniti
certamente no).
Post by Alessandro Feltrin
Mi sembra che questo potrebbe essere facilmente utilizzato per
giustificare l'inefficienza del servizio postale (tipo, "ma se hai
mandato una comunicazione senza richiedere la ricevuta di ritorno è già
tanto che arrivi").
Purtroppo, temo non ci fossero eccezioni nei casi -noti alla cronaca e
al contribuente incavolato- in cui si siano scoperti mucchi di posta non
consegnata abbandonati o incamerati illecitamente: le raccomandate A.R.
erano li' col resto. Sospetto che le indagini abbiano portato risultati
anche grazie a tracce mancanti delle stesse nei registri interni delle
Poste. Chissa' se a qualcuno e' mai venuto in mente di pigliare i
responsabili e schiaffarli a lavorare nel Regno Unito, ad affrontare
personalmente le conseguenze di eventuali ulteriori omissioni. ;-) Ma
forse costerebbe troppo.
Post by Alessandro Feltrin
Post by Marco Ermini
Negli USA ne hanno quattro tipi se non ricordo male: certified Mail
(dark green form), return receipt (light green form), delivery
confirmation (neon green form) e signature confirmation (neon pink
form).
http://www.usps.com/send/waystosendmail/extraservices/returnreceiptservice.htm
Gli USA hanno una mentalita' imprenditoriale, talvolta anche troppo:
l'esistenza di differenti livelli di servizio mostra semplicemente
l'esistenza di una posta "Chevrolet" e di una posta "Buick" con la
stessa scocca, diversi livelli di equipaggiamento e un diverso tipo di
acquirente. Ce l'hanno nel sangue, insomma.
Andrebbe capito, piuttosto, in quali casi le istituzioni statunitensi
richiedono espressamente l'uso di uno di questi canali: finora, non e'
affatto chiaro. Le Raccomandate A.R. italiane si possono mandare anche
tra privati per raccontarsi il tempo che fa (o, piu' facilmente, al
posto di una telefonata d'affari, specialmente se la materia da
discutere e' parecchia e/o va poi conservata in archivio con riferimenti
certi sulle date) ma non e' questo lo scenario principale che rende
utile lo strumento. La PEC e' nata principalmente per rispondere ad
un'esigenza dello Stato, che e' tutta un'altra cosa ed e' espressa
tramite normative emesse dallo Stato medesimo. Altri ne avranno di
analoghe, forse; solo che finora non sono saltate fuori. Qualcuno dei
presenti ha fonti sicure da interrogare in materia?
Post by Alessandro Feltrin
Post by Marco Ermini
Anche in Germania esiste e si chiama Bestätigungbrief, ed esiste pure
http://www.deutschepost.de/dpag?tab=1&skin=hi&check=yes&lang=de_DE&xmlFile=1015458
Che mi pare sia un servizio postale di Deutsche Post. Non un obbligo di
legge (ma su questo potrei sbagliarmi ...).
Concordo sul fatto che l'esistenza di un servizio non comporta
necessariamente la sua obbligatorieta', ne' definisce gli ambiti di
applicazione.
Post by Alessandro Feltrin
E comunque non è una buona ragione per sostenere la PEC ...
Come tutti coloro che ritengono che Internet sia un ambiente da
sfruttare in maniera differente e complementare (richiedendo, pertanto,
anche un diverso modo di trattare i problemi), mi associo senz'altro.
Sono poi opinioni: secondo me, ad esempio, la validita' di una soluzione
dipende esclusivamente da due fattori: se e' concettualmente utile e se,
una volta in pratica, la sua utilita' si trasforma in un vantaggio
effettivo.
I paragoni con altre nazioni sono comunque pericolosi per una ragione
piuttosto importante: le rispettive condizioni interne degli Stati non
sono mai le stesse, e questo significa che insistere per copiare una
buona idea altrui quando non siamo ancora pronti per attuarla potrebbe
finire per avere la stessa utilita' del buttare il fiato in una Vuvuzela
solo perche' "gli altri ce l'hanno gia'". :-D
In Italia, prima di "digitalizzare lo Stato" (delle imprese mi astengo
dal parlare, ci vorrebbe un altro thread ancora) bisognerebbe, a mio
avviso, superare serie barriere culturali che sono ancora di la'
dall'essere soltanto smosse; ovvero diffondere una cultura tecnica
paragonabile a quella portata dal settore dell'automobile. Ritengo che
mettere li' lo strumento, magari nato gia' male perche' creato piegando
la tecnica alle caratteristiche della burocrazia (quando e' molto piu'
produttivo e "moderno" fare l'opposto), potrebbe significare solo averlo
li', come tanti computer nuovi erano nelle scuole appena una quindicina
d'anni fa.
Il caso piu' plateale di una tecnologia con fortune dipendenti
esclusivamente dalla nazione in cui e' stata applicata e' quello della
telematica pubblica, con una tecnologia praticamente identica nei due
casi: Videotel da noi, Minitel in Francia. Abbiamo dovuto aspettare la
massificazione di Internet (e quanto la stiamo pagando cara!) per
recuperare uno svantaggio non solo tecnologico, ma anche culturale, nei
confronti dei nostri "vicini".

Infine il dubbio: continuiamo a parlarne qui, oppure ci spostiamo in
massa su it.soc.cybersocieta o qualche altro non-luogo del genere? ;-)


un saluto
Marcello Magnifico
Stefano Zanero
2010-07-13 11:27:58 UTC
Permalink
Post by Marcello Magnifico
Infine il dubbio: continuiamo a parlarne qui, oppure ci spostiamo in
massa su it.soc.cybersocieta o qualche altro non-luogo del genere? ;-)
La risposta e': per il valore legale della PEC e simili, spostatevi su lex.

Ormai stiamo derapando verso la filosofia ;-)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
Claudio Telmon
2010-07-07 14:28:51 UTC
Permalink
Post by Marco Ermini
Anche in Germania esiste e si chiama Bestätigungbrief, ed esiste pure
http://www.deutschepost.de/dpag?tab=1&skin=hi&check=yes&lang=de_DE&xmlFile=1015458
Da quello che leggo dovrebbe essere solo il servizio di CA delle poste
tedesche e un servizio di firma in ASP,
http://www.deutschepost.de/dpag?tab=1&skin=hi&check=yes&lang=de_DE&xmlFile=link1015460_55269
ma senza questioni di prove di consegna di messaggi. Ammetto che il mio
tedesco è un po' arrugginito...

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Ermini
2010-06-13 21:09:10 UTC
Permalink
[...]
Penso che è, quasi, la norma conservare nei propri DB le password in chiaro
specialmente per la posta elettronica, almeno nell'ambito dei medi/grossi
ISP. Non è invece la norma ne tanto meno elegante farlo sapere in giro.
Penso che sia un errore grave quasi quanto sbagliare ancora il congiuntivo :-)

E non esiste alcuna necessità per farlo (intendo, conservare la
password, non sbagliare il congiuntivo...) se non per la pigrizia - o
l'ignoranza - di implementare un sistema di password self-reset.

È forse per questo amo i provider che sono costretti a rispettare
certe compliance, perché sono costretti dagli auditor a non fare certe
porcherie. Grazie per esistere ISO27001! purtroppo non esistono multe
abbastanza salate in certi casi
Le password i chiaro sono utili per attività di help-desk, fondamentali in
caso di migrazioni o altre attività straordinarie.
Sono assolutamente in disaccordo, non hanno alcun senso in entrambi i
casi. E in nessun altro, per quel che possa immaginarmi... Per lo meno
in ambiti che siano _minimamente_ professionali.
Però un conto è
mantenerle per solo questo tipo di attività ed n conto è inviarle in chiaro,
specie per la PEC.
Non ha senso mantenerle in chiaro, punto. Fammi un solo esempio in cui
ti serva la password di un utente!
Noi quando installiamo un mail server per questo genere di contesti facciamo
presente al cliente che è possibile mantenere in chiaro una copia della
password, se lui lo ritiene opportuno ci specifica che vuole avere anche le
password in chiaro. Poi a livello di sistema questa password in chiaro non è
mai utilizzati dai software che fanno sempre riferimento ad un hash per il
confronto delle password fornite dall'utente, si tratta solo di un campo
extra nel DB. Qualcuno le vuole, altri no. Noi facciamo presente i pro ed i
contro poi decidano loro.
Bene, grazie per l'informazione. Aggiungo alla mia già lunga black
list dei fornitori di servizi italiani... non si sa mai, mi dovesse
servire una PEC un giorno...
Certo non è bello sapere che nei DB dei grossi ISP ci sono le nostre
password anche in chiaro.
Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati
sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre
password in chiaro.
Riterrei ancora meglio che venissero obbligati ad essere compliant
ISO27001 - o qualsiasi altro standard - e venissero obbligati a
lavorare professionalmente, ovvero conservassero soltanto gli hash
delle password ed implementassero dei seri e sicuri meccanismi di
password self-reset, dove chiunque non possa telefonare ad un help
desk spacciandosi per il cliente e facendosi leggere al telefono - o
mandare per email - la password della PEC

Mi meraviglia piuttosto che si possano veramente scrivere certe cose
in una mailing list di sicurezza. Magari altrove, ma non qua...


Cordiali saluti
--
Marco Ermini
***@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Ing. Stefano Centineo - AMAP S.p.A
2010-06-11 13:21:51 UTC
Permalink
Carissimo
Post by Dario Fiumicello
Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.
E non sei il primo e solo :-)
Post by Dario Fiumicello
Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!
ed Ú normale.... nella stragrande maggiornaza dei casi.
un poco meno per un sistema "certificato"..
Post by Dario Fiumicello
Personalmente mi sembra una grossa falla di sicurezza considerando che
- Se la password mi arriva in chiaro significa che sui loro DB Ú in
chiaro, e questo già non Ú bene
- La password arriva su una casella di posta classica, senza nessuna
cifratura!
.. il fatto che sia in chiaro sui "db" implica un'eventuale falla sui
sistemi del provider certificato. Ma del resto quanti sistemi di posta
in uso hanno le passwd cifrate ?
Post by Dario Fiumicello
Che ne pensate?
C'Ú stato da poco un lungo thread in lista in merito alla protezione
dei dati e certezza della ricezione.
Ad oggi quanto dici aggiunge vulnerabilità (sempre che la pwd sia
settata con "criterio") ma da quanto già risposto da altri il criterio
di "auto reset" presente in migliaia di altri esempi di web mailer,
evidentemente, Ú stato considerato troppo oneroso.

PS: se la casella "trusted" di recovery Ú in possesso ad un probabile
attaccante anche questo ultimo sistema... fa acqua in quanto a
sicurezza

a voi le ulteriori considerazioni.

Stefano
ag
2010-06-10 20:09:12 UTC
Permalink
Il giorno Wed, 9 Jun 2010 16:55:39 +0200
Post by Dario Fiumicello
Ciao a tutti
Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.
Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!
Personalmente mi sembra una grossa falla di sicurezza considerando che
- Se la password mi arriva in chiaro significa che sui loro DB Ú in
chiaro, e questo già non Ú bene
Quindi la password te la ricordavi?
Perché potrebbero benissimo aver sovrascritto quella precedente con
questa nuova.
Post by Dario Fiumicello
- La password arriva su una casella di posta classica, senza nessuna
cifratura!
Che ne pensate?
Dopo esserti loggato sul tuo account ti Ú impossibile cambiarla?

saluti
ag
Luca Berra
2010-06-11 17:37:04 UTC
Permalink
Post by Dario Fiumicello
Ciao a tutti
Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.
Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!
benvenuto,
personalmente ho sempre ritenuto la pec un enorme p.....ata,
la maggior parte dei problemi che la pec dovrebbe risolvere potrebbero
essere gestiti meglio con una PKI.
resterebbero le date di invio e di consegna.
la prima era risolvibile con qualche smtp server che la pubblica
amministrazione potrebbe gestire in autonomia.
la seconda anche adesso e' imho contestabile.

L.
--
Luca Berra -- ***@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-12 13:31:31 UTC
Permalink
Post by Luca Berra
la maggior parte dei problemi che la pec dovrebbe risolvere potrebbero
essere gestiti meglio con una PKI.
Forse allora non conosci benissimo cosa sia la PEC...

A parte che l'infrastruttura PEC ovviamente usa una PKI, forse tu
intendevi dire "i problemi che la PEC dovrebbe risolvere potrebbero
essere gestiti meglio con un'infrastruttura di firma digitale".

Purtroppo, come gia' ampiamente spiegato, le due cose sono simmetriche e
risolvono problemi diversi.
Post by Luca Berra
resterebbero le date di invio e di consegna.
Che sono L'UNICA cosa che la PEC garantisce, visto che la PEC non
garantisce l'autenticazione del mittente del messaggio (garantisce
l'autenticazione della casella mittente, che non e' necessariamente
collegata ad una persona fisica).
Post by Luca Berra
la prima era risolvibile con qualche smtp server che la pubblica
amministrazione potrebbe gestire in autonomia.
la seconda anche adesso e' imho contestabile.
Questa parte di messaggio, scritta cosi', e' priva di senso. Se provi a
rispiegarti magari siam d'accordo.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Luca Berra
2010-06-14 18:04:09 UTC
Permalink
Post by Stefano Zanero
Post by Luca Berra
la maggior parte dei problemi che la pec dovrebbe risolvere potrebbero
essere gestiti meglio con una PKI.
Forse allora non conosci benissimo cosa sia la PEC...
A parte che l'infrastruttura PEC ovviamente usa una PKI, forse tu
intendevi dire "i problemi che la PEC dovrebbe risolvere potrebbero
essere gestiti meglio con un'infrastruttura di firma digitale".
corretto
Post by Stefano Zanero
Purtroppo, come gia' ampiamente spiegato, le due cose sono simmetriche e
risolvono problemi diversi.
Post by Luca Berra
resterebbero le date di invio e di consegna.
Che sono L'UNICA cosa che la PEC garantisce, visto che la PEC non
garantisce l'autenticazione del mittente del messaggio (garantisce
l'autenticazione della casella mittente, che non e' necessariamente
collegata ad una persona fisica).
supponevo che una casella PEC dovesse essere associata ad una persona
giuridica, sbaglio anche qui?
Post by Stefano Zanero
Post by Luca Berra
la prima era risolvibile con qualche smtp server che la pubblica
amministrazione potrebbe gestire in autonomia.
la seconda anche adesso e' imho contestabile.
Questa parte di messaggio, scritta cosi', e' priva di senso. Se provi a
rispiegarti magari siam d'accordo.
provo a fare l'esempio con la raccomandata, che e' la cosa a cui la PEC
viene assimiliata:
In teoria, quando ricevo una raccomandata dovrei firmare al postino un
modulo per ricevuta.
La firma su questo pezzo di carta certifica che _io_ ho ricevuto la
mail.
L'implementazione della PEC e' piu' simile a:
Quando io ricevo una raccomandata, il postino firma un modulo ....


IMHO l'unico modo di certificare la data di uno scambio tra due parti e'
che entrambe le parti certifichino la data dell'avvenuto scambio.

Il metodo adottato con la PEC: scelgo una terza parte, con abbastanza
soldi per reggere ad una causa legale, che certifichi la data, resta
(sempre IMHO) una p.....ata.

L.
--
Luca Berra -- ***@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2010-06-14 20:00:43 UTC
Permalink
Post by Luca Berra
supponevo che una casella PEC dovesse essere associata ad una persona
giuridica, sbaglio anche qui?
Potrebbe anche essere associata ad un ufficio di una PA, per dire.

L'esempio sulla raccomandata l'abbiamo gia' fatto 100 volte, la posta
certificata crea un obbligo in capo al destinatario di controllare la
casella, e' vero, e' cosi', e' diverso dalla raccomandata cartacea, ha
lo stesso valore, fatevene una ragione.

(e comunque non spiega perche' ci debba importare della password della
casella)
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Pandolfi
2010-06-30 12:36:18 UTC
Permalink
Post by Stefano Zanero
Potrebbe anche essere associata ad un ufficio di una PA, per dire.
infatti.
ma alcuni gestori di domini pec, rilasciano la pec <servizio>@pec.pa.it
ad una persona fisica (identificata mezzo c.i.), che poi deve delegare,
firmando un modulo, altri dipendenti alla gestione della pec.

allora mi domando a cosa serve richiedere un documento di riconoscimento!

mp

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco d'Itri
2010-06-17 16:10:02 UTC
Permalink
Post by Luca Berra
IMHO l'unico modo di certificare la data di uno scambio tra due parti e'
che entrambe le parti certifichino la data dell'avvenuto scambio.
Il problema che la PEC (e le raccomandate, su cui è modellata) vuole
risolvere è più sottile: è un sistema che pretende di certificare la
consegna di una comunicazione a un destinatario che in quel momento ha
interesse a fingere di non averla ricevuta.
È inevitabile che per risolvere questo specifico problema sia necessaria
una trusted third party, ma sarei felice di essere smentito. :-)
Che poi abbia senso mettere in piedi questa enorme cagata che è la PEC
solo per risolvere questo caso particolare è un altro discorso...

Se il destinatario della comunicazione NON ha interesse a fingere di non
averla ricevuta allora basta che il suo MUA invii una ricevuta da lui
firmata, che sarebbe una piccola estensione dell'email standard
implementabile sugli endpoint senza bisogno di una nuova infrastruttura
ad hoc come quella della PEC.
È più o meno quello che ha fatto il ministero della difesa francese con
un fork di Thunderbird: www.trustedbird.org .
Ma questo risolverebbe solo un problema, non creerebbe una industria di
oligopolisti. :-)
--
ciao,
Marco
Claudio Telmon
2010-06-21 09:34:58 UTC
Permalink
Post by Marco d'Itri
Che poi abbia senso mettere in piedi questa enorme cagata che è la PEC
solo per risolvere questo caso particolare è un altro discorso...
Abbiamo un patrimonio di norme e regolamenti i cui equilibri si
appoggiano aulla possibilità di dimostrare di aver inviato una
comunicazione. Considera tutte le notifiche nei contesti giudiziari e
fiscali, per non parlare di multe, convocazioni, concorsi ecc.
Rinunciare a questa possibilità vorrebbe dire stravolgere le nostre
normative per appoggiarsi alle nuove possibilità offerte dalle
comunicazioni elettroniche, o rinunciare a queste ultime. Io preferisco
vedere uno strumento con i suoi limiti, ma che cerca di ricalcare i
meccanismi attuali, piuttosto che immaginare il legislatore, con la sua
cultura informatica, che cerca di "innovare" la normativa (uno scenario
da brivido). E come dici tu, serve una terza parte, non ci vedo molte
alternative, e non ho ancora sentito alternative papabili. Secondo me,
la PEC richiederebbe poche modifiche per risolvere molti dei problemi di
cui parliamo. Alcune mi sembrano banali (ma magari mi sfugge qualcosa),
come ad esempio stabilire e certificare la ricezione del messaggio non
al momento della consegna in casella ma al primo accesso successivo da
parte del titolare, che rimapperebbe correttamente l'andare a ritirare
la raccomandata alle poste.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2010-06-12 13:31:47 UTC
Permalink
Post by Luca Berra
Post by Dario Fiumicello
Ciao a tutti
Ho una casella PEC fornita dall'ordine degli ingegneri della mia città
e gestita da aruba. L'altro giorno volevo entrare ma non ricordavo la
password.
Clicco sul link del remainder e mi viene spedita nella mia casella di
posta elettronica NON CERTIFICATA la password per accedere alla PEC IN
CHIARO!
benvenuto,
personalmente ho sempre ritenuto la pec un enorme p.....ata,
Io invece pensavo ad una c....ata. Ma credo che la sostanza sia la
medesima ;)
Post by Luca Berra
la maggior parte dei problemi che la pec dovrebbe risolvere potrebbero
essere gestiti meglio con una PKI.
Il che renderebbe la PEC utilizzabile anche al di fuori dei confini
italiani. Ma sarebbe stato aspettarsi troppo dai nostri amati italici
capoccioni.
Post by Luca Berra
resterebbero le date di invio e di consegna.
la prima era risolvibile con qualche smtp server che la pubblica
amministrazione potrebbe gestire in autonomia.
O un'altra manciata di altre soluzioni sostanzialmente *STANDARD*, senza
la necessita` di dover inventare una intera infrastruttura.
Post by Luca Berra
la seconda anche adesso e' imho contestabile.
Andrea Adami
2010-06-23 20:15:37 UTC
Permalink
Post by Claudio Telmon
cui parliamo. Alcune mi sembrano banali (ma magari mi sfugge qualcosa),
come ad esempio stabilire e certificare la ricezione del messaggio non
al momento della consegna in casella ma al primo accesso successivo da
parte del titolare, che rimapperebbe correttamente l'andare a ritirare
la raccomandata alle poste.
A me sfugge dov'è il problema:
Se non sei in casa il postino di lascia l'avviso ma se tu non apri la
Tua cassetta della posta (perché ad esempio sei in ferie) non lo vedrai mai.
Se tu non vai a ritirare la raccomandata non per questo si ritiene non consegnata
Prova a non ritirare la raccomandata di una multa o di una sanzione di lì a un po'
o di li a un tanto (dipende dall'ente) ti fanno il blocco amministrativo della macchina.
E d'altra parte aspettare l'accesso del titolare prima di considerare consegnato un
Messaggio aprirebbe la porta ai soliti furbi che non accederebbero mai.
Secondo me la PEC automatizza la raccomandata punto.
Aggiungendo anzi qualcosa: l'autenticazione del mittente.
Diverso è il discorso sui meccanismi di recupero delle password dimenticata

Ciao
Andrea

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Telmon
2010-06-28 07:04:08 UTC
Permalink
Post by Andrea Adami
Se non sei in casa il postino di lascia l'avviso ma se tu non apri la
Tua cassetta della posta (perché ad esempio sei in ferie) non lo vedrai mai.
Se tu non vai a ritirare la raccomandata non per questo si ritiene non consegnata
Prova a non ritirare la raccomandata di una multa o di una sanzione di lì a un po'
o di li a un tanto (dipende dall'ente) ti fanno il blocco amministrativo della macchina.
Perché molti termini partono da quando ritiri la raccomandata, se la
ritiri, non da quando ti arriva l'avviso. Questo per dare a te il tempo
di agire, opporti ecc. Non sto ipotizzando che tu non ritiri la
raccomandata, ma che tu, come è normale, a volte non ci sia e quindi la
ritiri dopo qualche giorno.
I termini per pagare la multa decorrono da quando ritiri la notifica. Se
la ritiri dopo quindici giorni perché sei all'ospedale, i termini
decorrono da quel momento. Se i termini decorressero da quando ti viene
messo l'avviso nella buca, perderesti quindici giorni senza aver potuto
fare niente. Con la PEC, i termini decorrono da quando ti arriva l'avviso.
Post by Andrea Adami
E d'altra parte aspettare l'accesso del titolare prima di considerare consegnato un
Messaggio aprirebbe la porta ai soliti furbi che non accederebbero mai.
Che è come non ritirare mai una raccomandata, al che come dici tu arriva
il blocco amministrativo della macchina. Non è una questione di "soliti
furbi": tutti questi meccanismi servono proprio per gestire queste
situazioni in cui il destinatario non collabora. Altrimenti, come già
detto da qualcuno, basterebbero gli attuali meccanismi di "ricevuta" dei
MUA.
Post by Andrea Adami
Secondo me la PEC automatizza la raccomandata punto.
No :)
Post by Andrea Adami
Aggiungendo anzi qualcosa: l'autenticazione del mittente.
No :) L'autenticazione del mittente, come ha più volte sottolineato
Stefano, non è fornita dalla PEC in quanto tale, anche se secondo me la
cosa è in un limbo del tutto inappropriato per uno strumento di questo
tipo (dovrebbe essere dichiarato molto chiaramente se il mittente si
suppone autenticato o no).

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Flavio Visentin
2010-07-10 15:06:04 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Andrea Adami
Se non sei in casa il postino di lascia l'avviso ma se tu non apri la
Tua cassetta della posta (perché ad esempio sei in ferie) non lo vedrai mai.
Se tu non vai a ritirare la raccomandata non per questo si ritiene non consegnata
Prova a non ritirare la raccomandata di una multa o di una sanzione di lì a un po'
o di li a un tanto (dipende dall'ente) ti fanno il blocco amministrativo della macchina.
Non è propriamente così. La compiuta giacenza avviene solo per gli atti
giudiziari o fiscali; per tutte le altre raccomandate tra privati la
raccomandata si intende ricevuta solo quando torna indietro l'avviso di
ricevimento firmato, altrimenti è "non consegnata".
La PEC invece considera la mail ricevuta nel momento in cui è depositata
nella cassetta della posta, a prescindere che qualcuno la legga o meno.

- --
Flavio Visentin
GPG Key: http://www.zipman.it/gpgkey.asc

There are only 10 types of people in this world:
those who understand binary, and those who don't.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw4jFgACgkQusUmHkh1cnqW1wCfa6GtEfO/RuDXCkoXZFDIVrbm
f6YAnA/ipzOAypRWleB+6sgiFVhNxzsS
=MxPm
-----END PGP SIGNATURE-----
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Andrea Adami
2010-06-29 09:01:49 UTC
Permalink
Post by Marco d'Itri
Non equivale a una raccomandata, ma risolve il 99% dei casi (quelli in
cui il destinatario non ha interesse a fare finta di non avere ricevuto
il messaggio).
A mio avviso la raccomandata serve perché nel 99% dei casi il destinatario
ha interesse a far finta di non averla ricevuta.
Se non fosse così la normale ricevuta di lettura sarebbe sufficiente ..

Ciao
Andrea

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Raffaele
2010-06-30 14:45:41 UTC
Permalink
Post by Stefano Zanero
Post by giobbe
Cosa succede se non aprite la mailbox? Il messaggio risulta comunque
consegnato, di conseguenza e' colpa vostra se non lo aprite.
Esatto.
Nel caso in cui la casella PEC e' piena (magari volutamente) i messaggi
rimbalzano indietro. In questa situazione, dal punto di vista
legislativo, il destinatario e' considerato in dolo oppure no?
Mi sembra un punto critico, perche' se il mittente viene considerato in
dolo si aprono le porte a vendette trasversali a suon di messaggi
"bomba" (cioe' di dimensioni esagerate) che mandano fuori uso la casella
del malcapitato prima dell'invio di un messaggio vero, se non viene
considerato in dolo ecco un escamotage per aggirare la PEC da parte di
destinatari non collaborativi. Attendo lumi.

Ciao
Raffaele
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Telmon
2010-07-01 12:55:19 UTC
Permalink
Post by Raffaele
Nel caso in cui la casella PEC e' piena (magari volutamente) i messaggi
rimbalzano indietro. In questa situazione, dal punto di vista
legislativo, il destinatario e' considerato in dolo oppure no?
Se una raccomandata non può essere consegnata, ritorna al mittente o gli
arriva un avviso di mancata consegna. Quello che succede di conseguenza
è già definito e non è un problema della PEC.

ciao

- Claudio
--
Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Gelpi Andrea
2010-09-23 17:16:48 UTC
Permalink
Post by Claudio Telmon
Post by Raffaele
Nel caso in cui la casella PEC e' piena (magari volutamente) i messaggi
rimbalzano indietro. In questa situazione, dal punto di vista
legislativo, il destinatario e' considerato in dolo oppure no?
Se una raccomandata non può essere consegnata, ritorna al mittente o gli
arriva un avviso di mancata consegna. Quello che succede di conseguenza
è già definito e non è un problema della PEC.
ciao
- Claudio
Esistono delle rilevanze legali, ma al momento non esistono sanzioni, se
non il fatto che, ad esempio, i professionisti che fossero in questa
situazione saranno automaticamente esclusi dal poter lavorare con le PA
stesse.
Per i dettagli crdo sia meglio spostarsi su LEX.
--
ing. Andrea Gelpi
***************************************************
La Terra non la abbiamo ereditata dai nostri avi,
ma la abbiamo presa in prestito dai nostri bambini.
***************************************************
Continue reading on narkive:
Loading...