ma esiste un qualche motivo ragionevole per usare la password come chiave primaria?

Marcoxxx

unread,

Jul 15, 2021, 5:31:49 AM7/15/21

to

Chiedo perché una coppia di miei conoscenti (entrambi ultraottantenni)
mi ha chiesto una mini consulenza per capire perché l'attivazione dello
SPID ad uno di loro funzionava e all'altro no. E' venuto fuori che
praticamente avevano scelto la stessa password e il sistema, che aveva
fatto andare avanti il primo di loro senza problemi, non faceva andare
avanti il secondo, limitandosi a segnalare un generico errore. Quando il
secondo ha scelto una password diversa dal primo il sistema non ha più
protestato e ha fatto andare avanti anche il secondo.

C'è un logica in tutto questo, visto che potrebbe capitare che due che
non si conoscono scelgano la stessa password e in quel caso il secondo
non va avanti e nessuno capisce perché ?

Ciao,
Marco.

--
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus

Roberto Tempesti

unread,

Jul 15, 2021, 6:52:12 AM7/15/21

to

Il 15/07/2021 11:31, Marcoxxx ha scritto:
> Chiedo perché una coppia di miei conoscenti (entrambi ultraottantenni)
> mi ha chiesto una mini consulenza per capire perché l'attivazione dello
> SPID ad uno di loro funzionava e all'altro no. E' venuto fuori che
> praticamente avevano scelto la stessa password e il sistema, che aveva
> fatto andare avanti il primo di loro senza problemi, non faceva andare
> avanti il secondo, limitandosi a segnalare un generico errore. Quando il
> secondo ha scelto una password diversa dal primo il sistema non ha più
> protestato e ha fatto andare avanti anche il secondo.
>
> C'è un logica in tutto questo, visto che potrebbe capitare che due che
> non si conoscono scelgano la stessa password e in quel caso il secondo
> non va avanti e nessuno capisce perché ?
>
> Ciao,
> Marco.
>

Non ci credo nemmeno se lo vedo con i miei occhi.

--
The three most dangerous things in the world are a programmer with a
soldering iron, a hardware type with a program patch and a user with an
idea.

“Alles hat ein Ende, nur die Wurst hat zwei”

Giangi72

unread,

Jul 15, 2021, 6:55:20 AM7/15/21

to

Il 15/07/2021 11:31, Marcoxxx ha scritto:

> Chiedo perché una coppia di miei conoscenti (entrambi ultraottantenni)
> mi ha chiesto una mini consulenza per capire perché l'attivazione dello
> SPID ad uno di loro funzionava e all'altro no. E' venuto fuori che
> praticamente avevano scelto la stessa password e il sistema, che aveva
> fatto andare avanti il primo di loro senza problemi, non faceva andare
> avanti il secondo, limitandosi a segnalare un generico errore. Quando il
> secondo ha scelto una password diversa dal primo il sistema non ha più
> protestato e ha fatto andare avanti anche il secondo.
>
> C'è un logica in tutto questo, visto che potrebbe capitare che due che
> non si conoscono scelgano la stessa password e in quel caso il secondo
> non va avanti e nessuno capisce perché ?

Bha, motivi non ne vedo e mi sembrerebbe strano, io non ho mai visto la
password come chiave, da sola o come conchiave insieme al nome utente.

Vedo, al limite, un problema temporaneo del server ma senza altre
informazioni è difficile.
Giangi

ma...@daqualcheparte.it

unread,

Jul 15, 2021, 7:20:16 AM7/15/21

to

Marcoxxx <aritop...@web.de> wrote:

> l'attivazione dello
> SPID ad uno di loro funzionava e all'altro no. E' venuto fuori che
> praticamente avevano scelto la stessa password e il sistema, che aveva
> fatto andare avanti il primo di loro senza problemi, non faceva andare
> avanti il secondo, limitandosi a segnalare un generico errore.

E questo per te sarebbe sufficente per dedurre che sia stata
utilizzata "la password come chiave primaria"? Andiamo bene.

A parte il discorso che ci sono diversi punti della storia
raccondataci che fanno acqua, ma li sorvolo.

Ti avevo già suggerito, ma - di tutta evidenza - non ti arriva al
cervello: Lascia perdere, ogni volta che ti attacchi alla tastiera non
fai che palesare le tue incompetenze informatiche, così anche ai
ciechi può risultare evidente perché "non fai più l'informatico". Ti
rinnovo il suggerimento: Lascia perdere le tue frustrazioni e i tuoi
fallimenti personali e rivolgiti a qualche bravo psichiatra. Ma
qualcosa mi dice che quest'ultima cosa è in atto già da anni (anche se
i risultati faticano a emergere).

John Smith

unread,

Jul 28, 2021, 4:13:03 AM7/28/21

to

On 15/07/2021 11:31, Marcoxxx wrote:
>
> C'è un logica in tutto questo, visto che potrebbe capitare che due che
> non si conoscono scelgano la stessa password e in quel caso il secondo
> non va avanti e nessuno capisce perché ?

A voler essere paranoici così si mettono al riparo da attacchi di tipo
"Password spray".
Nel caso gli bucherebbero un solo account.
Visti i grandi numeri dello SPID potrebbe anche avere il suo senso ...

> Ciao,
> Marco.

Ciao

M.

Marcoxxx

unread,

Jul 30, 2021, 10:03:54 AM7/30/21

to

Si', ma proprio visti i grandi numeri, chi gli assicura che due tizi che
non si conoscono tra loro non scelgano la stessa pwd ottenendo un errore
incomprensibile, dato che il secondo dei due che sceglie la stessa pwd
di un altro, non sa che c'è qualcun altro che prima di lui ha scelto la
stessa sua pwd (ed è bene che non lo sappia, visto che altrimenti
verrebbe a conoscenza di una delle password inserite nel db senza
bisogno di alcun tipo di attacco)

Ciao,
Marco

rootkit

unread,

Jul 30, 2021, 10:49:59 AM7/30/21

to

On Thu, 15 Jul 2021 11:31:45 +0200, Marcoxxx wrote:

> Chiedo perché una coppia di miei conoscenti (entrambi ultraottantenni)
> mi ha chiesto una mini consulenza per capire perché l'attivazione dello
> SPID ad uno di loro funzionava e all'altro no. E' venuto fuori che
> praticamente avevano scelto la stessa password e il sistema, che aveva
> fatto andare avanti il primo di loro senza problemi, non faceva andare
> avanti il secondo, limitandosi a segnalare un generico errore. Quando il
> secondo ha scelto una password diversa dal primo il sistema non ha più
> protestato e ha fatto andare avanti anche il secondo.
>
> C'è un logica in tutto questo, visto che potrebbe capitare che due che
> non si conoscono scelgano la stessa password e in quel caso il secondo
> non va avanti e nessuno capisce perché ?

quello che dici è una *puttanata*.

password uguali non generano hash uguali. e non può proprio esistere
nessun tipo di vincolo o controllo che due utenti non scelgano la stessa
password.

John Smith

unread,

Jul 30, 2021, 11:58:22 AM7/30/21

to

On 30/07/2021 16:03, Marcoxxx wrote:
>
> Si', ma proprio visti i grandi numeri, chi gli assicura che due tizi che
> non si conoscono tra loro non scelgano la stessa pwd ottenendo un errore
> incomprensibile, dato che il secondo dei due che sceglie la stessa pwd
> di un altro, non sa che c'è qualcun altro che prima di lui ha scelto la
> stessa sua pwd (ed è bene che non lo sappia, visto che altrimenti
> verrebbe a conoscenza di una delle password inserite nel db senza
> bisogno di alcun tipo di attacco)

Diciamo che, IMVHO, andrebbe curata un pochino la "gestione degli
errori", magari un generico, "password non valida" senza dare altre
spiegazioni sarebbe una soluzione acettabile ...

> Ciao,
> Marco

Ciao.

M.

John Smith

unread,

Jul 30, 2021, 12:00:03 PM7/30/21

to

On 30/07/2021 16:49, rootkit wrote:
>
> password uguali non generano hash uguali. e non può proprio esistere
> nessun tipo di vincolo o controllo che due utenti non scelgano la stessa
> password.
>

Azz, vero, immagazzini l'hash, non la pw ...

M.

ma...@daqualcheparte.it

unread,

Jul 30, 2021, 12:13:04 PM7/30/21

to

On 30/07/21 16:49, rootkit wrote:

> quello che dici è una *puttanata*.
>
> password uguali non generano hash uguali.

Lui ha detto, si, un sacco di puttanate, ma tu lo stai seguendo alla
grande...
Probabilmente hai avuto in mente altre cose, che hai preso come premesse
implicite (v. qualsiasi libro di logica classica), ma quello che hai
scritto è palesemente falso.

rootkit

unread,

Jul 30, 2021, 3:16:53 PM7/30/21

to

uhm.
mi stai dicendo che negli algoritmi di password hashing è passato di moda
il salt? :-)
cosa c'è di meglio di una dimostrazione empirica:

❯ echo "mypwd" | mkpasswd --method=SHA-512 --stdin
$6$rDd1Pa4AgtJPJefw$P15XGDMC935Zi/IsAeAA9XFT2ATRtwNmP9UkPJ7JlDiXBP0FcyPY/
DpZIwphM9vbk0vizi5JaXw2IH78FCaTq/
❯ echo "mypwd" | mkpasswd --method=SHA-512 --stdin
$6$pfZQKbXsKLtX8r/b$7U/
9crFJN8sM4115p8iDMQlOn21dJTIccbT0o9zoziH1ij7Jdvhk6vsR5YXYwoiKcvKXW8ITCin4ap9Hw/
cwv0

non so cosa avessi in mente tu quando hai scritto che è palesemente
falso, ma ovviamente su un database tu troverai sempre hash diversi anche
a parità di password. il motivo è evidente: se una password è
compromessa, automaticamente lo sarebbero anche tutte le altre uguali.
oltre al fatto che saresti vulnerabile al cosiddetto dictionary attack,
cioè se un malintenzionato arrivasse ad avere sotto mano il db molte
password non avrebbe nemmeno bisogno di attaccarle di forza bruta, le
riconoscerebbe a prima vista.

rootkit

unread,

Jul 30, 2021, 3:47:44 PM7/30/21

to

On Fri, 30 Jul 2021 16:03:51 +0200, Marcoxxx wrote:

> Si', ma proprio visti i grandi numeri, chi gli assicura che due tizi che
> non si conoscono tra loro non scelgano la stessa pwd ottenendo un errore
> incomprensibile, dato che il secondo dei due che sceglie la stessa pwd
> di un altro, non sa che c'è qualcun altro che prima di lui ha scelto la
> stessa sua pwd (ed è bene che non lo sappia, visto che altrimenti
> verrebbe a conoscenza di una delle password inserite nel db senza
> bisogno di alcun tipo di attacco)

sì ma ti rendi conto che ti stai facendo un film su una cosa che non
esiste?

se hai una password *non* puoi sapere se qualcun altro l'ha usata, a meno
di mettersi lì a verificarle tutte una per una.

e anche l'idea che quell'errore fosse dovuto al fatto che avevano usato
la stessa password... cioè l'avessi verificato su due o tre casi poteva
al limite venire un vago sospetto c'entrasse qualcosa, ma *uno*... ma poi
che fallisca un criterio di univocità password vuol dire pensare che
vengano salvate in chiaro, sul portale spid... dai, su.

rootkit

unread,

Jul 30, 2021, 5:33:09 PM7/30/21

to

On Thu, 15 Jul 2021 12:55:17 +0200, Giangi72 wrote:

> Bha, motivi non ne vedo e mi sembrerebbe strano, io non ho mai visto la
> password come chiave, da sola o come conchiave insieme al nome utente.

sarebbe una cosa priva di senso. primo, le password sono hashed: secondo,
sono salted. in altre parole se anche ci fosse un indice univoco non
potrebbe impedire di inserire due password identiche.

ma...@daqualcheparte.it

unread,

Jul 30, 2021, 8:33:34 PM7/30/21

to

On 30/07/21 21:16, rootkit wrote:

>> Probabilmente hai avuto in mente altre cose, che hai preso come premesse
>> implicite (v. qualsiasi libro di logica classica), ma quello che hai
>> scritto è palesemente falso.
>
> uhm.
> mi stai dicendo che negli algoritmi di password hashing è passato di moda
> il salt? :-)

No, sto dicendo che hai fatto delle premesse implicite (e ne hai fatte
parecchie, e me lo stai confermando).

Giusto una parentesi per gli equivoci in agguato: Degli "algoritmi di
hashing" nel senso proprio, virgolettato, (l'altro discorso è se il
termine "algoritmo" lo utilizziamo nel suo significato generico, come
sequenze di operazioni per risolvere un problema, dato che questo
secondo utilizza il primo come uno dei passaggi essenziali; In questo
caso preferisco parlare di "programma" o di "funzione" per evitare
equivoci) generalmente il sale non fa parte, semmai può far parte -
dunque - del "programma" o della "funzione" che da una stringa o da un
flusso di bit (un dato qualsiasi) con un altro dato qualsiasi (il sale)
produce un'altra stringa (un hash). E' una questione di nomenclatura, se
ci mettiamo d'accordo su quale significato utilizzare, non ho problemi a
convenire con te (anzi, già fatto qualche riga sopra, ma vedi anche
l'esempio di BCrypt riportato sotto).

> cosa c'è di meglio di una dimostrazione empirica:

> ...

La SALTo, perché completamente irrilevante.
Conosco bene diversi algoritmi e come anche diversi strumenti che li
implementano. Alcuni (mi viene in mente BCrypt, come esempio, che è
appunto, almeno inizialmente stato definito come "funzione", poi ci sono
quelli che fanno confusione e lo chiamano sia algoritmo che funzione:
https://en.wikipedia.org/wiki/Bcrypt ) lo fa quello che dici e come
dici. Una funzione così può utilizzare in sostanza un qualsiasi
"algoritmo di hashing", per esempio "blowfish". Il sale viene utulizzato
proprio perché un "algoritmo di hashing" produce sempre un hash uguale.
Per questo nel "programma", "funzione", o quello che è, il sale viene
messo.

Ma di nuovo, lasciamo da parte le nomenclature e le convenzioni sui
nomi, quello che voglio dire è che non è da dare per scontato che sia
stato utilizzato un programma di hashing, come quello. Tu dai per
scontato che tutti facciano il hashing (e con il sale), mentre ci sono
delle aziende, anche grosse (non faccio nomi), che scrivono apposta
tutti i dati in chiaro e registrano anche le credenziali inserite per
tutti i tentativi di accesso sbagliati, per motivi che non dovresti far
fatica a capire...
Non mi sorprenderebbe se venissi a sapere che nell'ente in questione la
pratica fosse esattamente questa.
Ma qui rischiamo di allontanarci troppo dal discorso iniziale.

> non so cosa avessi in mente tu quando hai scritto che è palesemente
> falso, ma ovviamente su un database tu troverai sempre hash diversi anche
> a parità di password.

Come già detto: premesse implicite. Ho visto (e rabbrividito) che in
molte aziende, nei db, salvano in chiaro dati che dovrebbero essere
segreti (e mi è stato proibito di modificarlo - con giustificazioni
banali e poco credibili: "quello che funziona non va toccato", dunque
non do mai per scontato niente. Non è questione di "mode", ma di
incompetenza che c'è in giro, ma a volte anche di ben precise strategie
di alcune "aziende canaglia".

rootkit

unread,

Jul 31, 2021, 5:02:38 AM7/31/21

to

On Sat, 31 Jul 2021 02:33:28 +0200, ma...@daqualcheparte.it wrote:

> Giusto una parentesi per gli equivoci in agguato: Degli "algoritmi di
> hashing" nel senso proprio, virgolettato, (l'altro discorso è se il
> termine "algoritmo" lo utilizziamo nel suo significato generico, come
> sequenze di operazioni per risolvere un problema, dato che questo
> secondo utilizza il primo come uno dei passaggi essenziali; In questo
> caso preferisco parlare di "programma" o di "funzione" per evitare
> equivoci) generalmente il sale non fa parte, semmai può far parte -
> dunque - del "programma" o della "funzione" che da una stringa o da un
> flusso di bit (un dato qualsiasi) con un altro dato qualsiasi (il sale)
> produce un'altra stringa (un hash). E' una questione di nomenclatura, se
> ci mettiamo d'accordo su quale significato utilizzare, non ho problemi a
> convenire con te (anzi, già fatto qualche riga sopra, ma vedi anche
> l'esempio di BCrypt riportato sotto).

io credo che l'equivoco lo si stia cercando col lanternino. si sta
parlando in ultima istanza di come la stringa hash viene salvata su un
qualsiasi database, ovvero di come si cripta correttamente (e
correntemente) una password. in questo processo il salt c'entra eccome.
così come è fondamentale il requisito a password uguale non deve
corrispondere hash uguale, perché sappiamo essere un allentamento di
sicurezza non da poco.
obiettare in questo modo mi pare un capellino capzioso.

>> cosa c'è di meglio di una dimostrazione empirica:
>> ...
>
> La SALTo, perché completamente irrilevante.

bah.

> Ma di nuovo, lasciamo da parte le nomenclature e le convenzioni sui
> nomi, quello che voglio dire è che non è da dare per scontato che sia
> stato utilizzato un programma di hashing, come quello. Tu dai per
> scontato che tutti facciano il hashing (e con il sale), mentre ci sono
> delle aziende, anche grosse (non faccio nomi), che scrivono apposta
> tutti i dati in chiaro e registrano anche le credenziali inserite per
> tutti i tentativi di accesso sbagliati, per motivi che non dovresti far
> fatica a capire...
> Non mi sorprenderebbe se venissi a sapere che nell'ente in questione la
> pratica fosse esattamente questa.

su un fornitore servizi spid? a me sorprenderebbe eccome. anch'io "ho
visto cose che voi umani" ma fino ad un certo punto. oggi il rischio è
talmente alto che se non hai un access management di grado enterprise è
solo questione di tempo che lo paghi a caro prezzo. altro che password in
chiaro sul db.

> Come già detto: premesse implicite. Ho visto (e rabbrividito) che in
> molte aziende, nei db, salvano in chiaro dati che dovrebbero essere
> segreti (e mi è stato proibito di modificarlo - con giustificazioni
> banali e poco credibili: "quello che funziona non va toccato", dunque
> non do mai per scontato niente. Non è questione di "mode", ma di
> incompetenza che c'è in giro, ma a volte anche di ben precise strategie
> di alcune "aziende canaglia".

calcoleranno il rischio. se sono semplicemente informazioni riservate il
giorno che le vedranno vendute sul "dark web" ne pagheranno di tasca loro
le conseguenze. se sono anche dati sensibili... beh auguri al titolare e
al dpo.

ma...@daqualcheparte.it

unread,

Jul 31, 2021, 5:28:09 AM7/31/21

to

On 31/07/21 11:02, rootkit wrote:
> On Sat, 31 Jul 2021 02:33:28 +0200, ma...@daqualcheparte.it wrote:

> io credo che l'equivoco lo si stia cercando col lanternino. si sta
> parlando in ultima istanza di come la stringa hash viene salvata su un
> qualsiasi database, ovvero di come si cripta correttamente (e
> correntemente) una password.

No, non "si sta parlando". L'OP non lo ha scritto, tu si. Pur convenendo
con te su quello che lui ha scritto, ho solo detto che non lo do per
scontato che utilizzino il hashing di nessun tipo.

> su un fornitore servizi spid? a me sorprenderebbe eccome. anch'io "ho
> visto cose che voi umani" ma fino ad un certo punto.

Anch'io supponevo l'esistenza di "un certo "punto". Ma lo vedo
continuamente spostare più un la'.

> calcoleranno il rischio. se sono semplicemente informazioni riservate il
> giorno che le vedranno vendute sul "dark web" ne pagheranno di tasca loro
> le conseguenze. se sono anche dati sensibili... beh auguri al titolare e
> al dpo.

Si, "va' e non peccare più"... Le vendite sul "dark web" rappresentano
solo la parte meno "dark" (ovvero meno sconosciuta, considerando anche
gli spostamenti di dati ancora più "oscuri" tra le multinazionali e i
certi governi, in relazione molti-a-molti). Sopratturro quando la
(eventuale) multa, dopo gli anni di ricorsi e cavilli perde il suo
significato nel contesto di ingenti profitti incassati nel frattempo,
investiti negli altri attivi (inizialmente non tassabili/tassati, perché
investimenti!), dei quali successivi profitti possono anche servire per
pagare la multa, se mai si arriva a quel momento. Tutta la finanza
tossica di oggi funziona esattamente così. O pensi che i GAFAM sono
multiultramegamiliardari per la qualità ed eccellenza dei loro prodotti
e servizi?
Ma, di nuovo, rischiamo di nuovo di andare "fuori tema".

rootkit

unread,

Jul 31, 2021, 9:33:35 AM7/31/21

to

On Sat, 31 Jul 2021 11:28:04 +0200, ma...@daqualcheparte.it wrote:

> On 31/07/21 11:02, rootkit wrote:
>> On Sat, 31 Jul 2021 02:33:28 +0200, ma...@daqualcheparte.it wrote:
>
>> io credo che l'equivoco lo si stia cercando col lanternino. si sta
>> parlando in ultima istanza di come la stringa hash viene salvata su un
>> qualsiasi database, ovvero di come si cripta correttamente (e
>> correntemente) una password.
>
> No, non "si sta parlando". L'OP non lo ha scritto, tu si.

non fingiamo di non capire. l'op ipotizza un errore di univocità della
password, questo presuppone quanto sopra. con la password gestita e
salvata correttamente non è possibile, ne convieni?

> Pur convenendo
> con te su quello che lui ha scritto, ho solo detto che non lo do per
> scontato che utilizzino il hashing di nessun tipo.

visto che si parla di chi gestisce l'identità digitale della pa, dare per
scontato che non salvino le password in chiaro non è così peregrino.
soprattutto non è un argomento per dire che ho scritto una puttanata.
cioè queste si chiamano illazioni, su cui si può ciaccolare quanto si
vuole, ma sempre illazioni restano.

ma...@daqualcheparte.it

unread,

Jul 31, 2021, 11:56:56 AM7/31/21

to

On 31/07/21 15:33, rootkit wrote:
> On Sat, 31 Jul 2021 11:28:04 +0200, ma...@daqualcheparte.it wrote:

> non fingiamo di non capire. l'op ipotizza un errore di univocità della
> password, questo presuppone quanto sopra. con la password gestita e
> salvata correttamente non è possibile, ne convieni?

Lui espone la sua certezza (!) che la password sia utilizzata come
chiave primaria, e te l'ho già scritto che convenivo con te per quanto
riguardava la valutazione che gli avevi dato, ma il tuo discorso, senza
rendere esplicite le premesse (e non puoi farlo se non conosci la realtà
aziendale in questione, puoi solo fare ipotesi e congetture, come hai
fatto in seguito, e se le prendi come premesse implicite, tanto peggio)
è un "nulla ne consegue" non molto distante dalla conclusione che aveva
fatto lui. Ma una volta resole esplicite, come hai fatto poi, quelle
sono, in linea di principio, confermabili o confutabili (nel senso che
chi lavora presso l'azienda in questione, sul progetto in questione,
potrebbe dire se la premessa sia vera o falsa). Io mi sono limitato
all'esporre il mio dubbio, e sotto ti riporto anche degli indizi perché
ritengo un tale dubbio giustificato (oltre all'esperienza personale già
riportata). Ti è chiaro il concetto di "premessa implicita"?
Ti potrei ri-raccomandare un qualsiasi testo di logica classica.

>> Pur convenendo
>> con te su quello che lui ha scritto, ho solo detto che non lo do per
>> scontato che utilizzino il hashing di nessun tipo.
>
> visto che si parla di chi gestisce l'identità digitale della pa, dare per
> scontato che non salvino le password in chiaro non è così peregrino.
> soprattutto non è un argomento per dire che ho scritto una puttanata.
> cioè queste si chiamano illazioni, su cui si può ciaccolare quanto si
> vuole, ma sempre illazioni restano.

Non ti ho detto che avevi scritto una puttanata (problemi di
comprendonio?), ma che la sua (io utilizzato il plurale e ho aggiunto
"un sacco") la fai seguire ("alla grande") da una cosa "palesamente
falsa" (ti ho spiegato perché, e lo ripeterei in altri contesti simili)
e ho anche detto che probabilmente hai fatto delle premesse implicite
(che portavano alle conclusioni che non dovrebbero; questa è una
conclusione implicita), se non le si espone come premesse (basate sui
fatti accertabili, dunque con la certezza di poter dire se un enunciato
sia vero o falso!), fatti che non conosci ne tu ne l'OP (ne io, del
resto, ma io non ho fatto nessuna congettura, ho solo scritto che non
davo per scontato niente, a differenza di te che continui a dare per
scontate delle cose e in base a quelle tiri le conclusioni per le quali
dico che "non ne conseguono").

Ecco, io non lo do per scontato affatto. Ma come già detto, fa parte di
un altro discorso, non quello dell'OP.

Per quanto riguarda l'ultima cosa da te scritta (e la mia promessa di
documentare i miei dubbi, oltre alle esperienze dirette), non so se
esiste qualche direttiva o circolare più recente (con ulteriori
restrizioni di sicurezza) di questa;

https://www.agid.gov.it/sites/default/files/repository_files/circolari/spid-regolamento_modalita_attuative_v1.pdf

"Questi file non devono mai contenere le password in chiaro;
allo scopo possono essere usate tecniche,come da standard
internazionali e approvate dall’Agenzia, di crittografia o algoritmi di
salt e hashing A livello 2 e 3 SPID, vale quanto indicato a livello 1
con i necessari allineamenti e conformità agli standard e alla normativa
vigente per i moduli crittografici e di sicurezza software/hardware. "

E' da notare il "non devono mai contenere le password in chiaro",
ma come puoi vedere "algoritmi di salt e hashing" è solo esposto in
guisa di consiglio, non come imperativo (e tutto condito con le solite
chiacchiere che possono dire tutto o niente). Ma niente obbliga i
fornitori di SPID di implementare hash senza sale (anche quello in
zucca). La cosa più interessante - e che probabilmente non ti è sfuggita
- è che parlano di "file", non di DB, non delle password degli utenti
(ma quelle interne). Svista/e? Mi permetto di "pensare male",
"commettendo peccato" come avrebbe detto Andreotti.

Un'altro documento, più recente (ma più generico e non inerente solo
allo SPID), non solo che NON aggiunge restrizioni, ma come "misure
minime" non tratta nemmeno argomenti come DB o hash:

https://www.agid.gov.it/sites/default/files/repository_files/documentazione/misure_minime_di_sicurezza_v.1.0.pdf

La direttiva citata nello stesso documento è questa:

https://www.agid.gov.it/sites/default/files/repository_files/documentazione/misure_minime_di_sicurezza_v.1.0.pdf

Anche qui nessun cenno di quello che dici tu.

Ripeto, non so se esiste qualche documento di rettifica (a me non è
conosciuto al momento, ti sarò grato se me lo riporti qui se ne sei a
conoscenza (dunque, dati verificabili, non le tue ipotesi!), e non si
tratta di cose "peregrine" come dici tu, ma se esistono le procedure
minime richieste, la maggior parte delle aziende utilizzerà proprio
quelle, solo quelle, e niente oltre a quelle).

E comunque anche se esistesse un documento così, mi terrei il dubbio
andreottiano, per motivi che ti ho esposto nel messaggio precedente.

M C

unread,

Jul 31, 2021, 1:38:16 PM7/31/21

to

On 31/07/2021 14:33, rootkit wrote:
> visto che si parla di chi gestisce l'identità digitale della pa, dare per
> scontato che non salvino le password in chiaro non è così peregrino.
> soprattutto non è un argomento per dire che ho scritto una puttanata.
> cioè queste si chiamano illazioni, su cui si può ciaccolare quanto si
> vuole, ma sempre illazioni restano.

sto dalla tua parte, in pieno. posso comunque portarti un esempio
raccapricciante: blasonata azienda 400+ dipendenti del centro Italia con
uffici e stabilimenti sparsi in mezza Europa e Russia, nel 2013 aveva
ancora le password del sistema documentale tecnico, accessibile da
Internet, in chiaro..

a nulla erano serviti i tentativi per convincerli a migrare, iniziati
nel... 2007, quando era venuto fuori l'inghippo. Dopo il 2013 e
soprattutto dopo l'assorbimento da parte di un'altra ben più blasonata
azienda americana e l'arrivo dello spauracchio GDPR non lo so come sia
finita

ok, è un'azienda privata, non PA, ma fa paura lo stesso...

ma...@daqualcheparte.it

unread,

Jul 31, 2021, 2:36:28 PM7/31/21

to

On 31/07/21 19:38, M C wrote:

> ok, è un'azienda privata, non PA, ma fa paura lo stesso...

https://www.investireoggi.it/tech/scandalo-facebook-password-utenti-leggibili-in-chiaro-per-mesi/

https://www.reddit.com/r/italy/comments/ictlav/unicocampania_data_breach_160mila_password/

https://tech.everyeye.it/notizie/un-bug-macos-high-sierra-mostrava-password-in-chiaro-307144.html

ecc.

rootkit

unread,

Jul 31, 2021, 4:09:03 PM7/31/21

to

On Sat, 31 Jul 2021 17:56:51 +0200, ma...@daqualcheparte.it wrote:

> E comunque anche se esistesse un documento così, mi terrei il dubbio
> andreottiano, per motivi che ti ho esposto nel messaggio precedente.

ma non è un problema, figurati. non so neanche perché siamo arrivati a
discutere in questi termini, non me ne frega nulla. una volta chiarito il
punto che a password uguali non corrispondono hash uguali per me era
finita lì.

rootkit

unread,

Jul 31, 2021, 5:05:18 PM7/31/21

to

On Sat, 31 Jul 2021 18:38:14 +0100, M C wrote:

> sto dalla tua parte, in pieno. posso comunque portarti un esempio
> raccapricciante:

sì ma infatti anch'io come dicevo ne potrei raccontare di ogni. ne scelgo
uno: gestionale interno con anche funzioni di workflow documentale, viene
fuori che non solo ci sono le password in chiaro ma anche tutte le
password uguali fra loro. chiedo spiegazioni al cto: "non vi preoccupate,
il gestionale è sotto single-sign-on e l'autenticazione locale è solo un
failover per quando non è disponibile. in emergenza, sai non possiamo
mica fermarci". già qui fa rabbrividire, ma ora viene il bello. gli feci
notare che bastava annullare la popup dell'autenticazione basic e
magicamente invece del forbidden compariva la form di login dove si
poteva entrare con qualsiasi username. la risposta del cto: "uhm, è vero
ma a chi vuoi venga in mente di fare una cosa del genere?". a nessuno,
figurati, al mondo son tutti fessi.

Marcoxxx

unread,

Aug 1, 2021, 5:35:10 AM8/1/21

to

Il 30/07/2021 21:47, rootkit ha scritto:
> On Fri, 30 Jul 2021 16:03:51 +0200, Marcoxxx wrote:
>
>

> e anche l'idea che quell'errore fosse dovuto al fatto che avevano usato
> la stessa password... cioè l'avessi verificato su due o tre casi poteva
> al limite venire un vago sospetto c'entrasse qualcosa, ma *uno*...

Mi spiego meglio: sono stati fatti 3-4 tentativi con l'utente che
aveva tentato di usare la stessa password che aveva usato per sua moglie (*)
in un intervallo di tempo di circa 30-40 minuti (proprio pensando che
fosse un problema temporaneo era stato fatto qualche tentativo
semplicemente "aspettando un po'"). Tutti i tentativi sono falliti con
un generico "errore nei dati" o qualcosa del genere (ovviamente non mi
ricordo la dicitura esatta).

Immediatamente dopo l'ultimo fallimento (quindi probabilmente neanche un
minuto dopo l'ultimo fallimento), è stato cambiato un singolo carattere
della pwd del secondo utente (e nessuna altra modifica è stata fatta).
Tutto ha funzionato perfettamente.
Determina pure te quale sia la probabilità che il problema fosse
temporaneo del sito e quale sia la probabilità che sia qualcosa legato
al fatto di avere due pwd uguali (a me va anche bene il fatto che non
sia il problema di avere la pwd come chiave primaria, ma qual è la
probabilità che il problema sia temporaneo del sito dopo che 3-4
tentativi distanziati di una decina di minuti l'uno dall'altro sono
tutti falliti e che un minuto dopo tutto funzioni avendo cambiato un
singolo carattere della password).

Ciao,
Marco.

(*) anche qui, ovviamente non mi ricordo se prima erano stati inseriti
i dati della moglie e poi quelli del marito o viceversa, ma poco cambia.

rootkit

unread,

Aug 1, 2021, 8:39:17 AM8/1/21

to

On Sun, 01 Aug 2021 11:35:03 +0200, Marcoxxx wrote:

> Immediatamente dopo l'ultimo fallimento (quindi probabilmente neanche un
> minuto dopo l'ultimo fallimento), è stato cambiato un singolo carattere
> della pwd del secondo utente (e nessuna altra modifica è stata fatta).
> Tutto ha funzionato perfettamente.

mettiamola così: intanto diciamo chi è questo provider spid, facciamo
un'altra prova (basta che una delle due persone reimposti la password
uguale all'altra) e se è confermato puoi dire di aver scoperto una
probabile falla grave. e non sto parlando dell'errore generico. posso
segnalarti un paio di esperti che sarebbero molto interessati alla
questione.

Marcoxxx

unread,

Aug 1, 2021, 2:43:14 PM8/1/21

to

Il 01/08/2021 14:39, rootkit ha scritto:
> On Sun, 01 Aug 2021 11:35:03 +0200, Marcoxxx wrote:
>
>

[SNIP]

> mettiamola così: intanto diciamo chi è questo provider spid, facciamo
> un'altra prova (basta che una delle due persone reimposti la password
> uguale all'altra) e se è confermato puoi dire di aver scoperto una
> probabile falla grave. e non sto parlando dell'errore generico. posso
> segnalarti un paio di esperti che sarebbero molto interessati alla
> questione.
>

Le persone sono anziane, ultraottantenni (anzi credo che alla fine
dell'anno saranno entrambe ultraottantacinquenni) e a livello di
conoscenze informatiche su una scala da 1 a 100 valgono rispettivamente
-564 e +4, nel senso che uno almeno è in grado di accendere il PC,
scrivere un'email, arrivare alla home page di un sito se ne conosce
l'url (ma già se poi c'è da interagire con il sito, potrebbe essere un
problema) e persino rispondere ad una chiamata Skype, se qualcuno gli ha
preventivamente impostato tutto collegando cuffie, microfono, webcam
ecc. (ma magari già se Skype gli chiede di installare gli aggiornamenti
potrebbe non sapere cosa fare). Non credo che riescano a fare molto più
di questo. Non credo che siano interessati a fare da "cavie" per un
esperimento che sicuramente non sono in grado di capire (figuriamoci
capire la gravità dell'eventuale falla). E ovviamente io non glielo
chiederò.

Comunque il provider è PI
(tra l'altro se il problema fosse veramente qualcosa di simile si spera
che se ne possano accorgere da soli e lo correggerlo).

Ciao,
Marco.

vitorio

unread,

Aug 5, 2021, 8:02:07 PM8/5/21

to

Il 15/07/2021 11:31, Marcoxxx ha scritto:

> Chiedo perché una coppia di miei conoscenti (entrambi ultraottantenni)
> mi ha chiesto una mini consulenza per capire perché l'attivazione dello
> SPID ad uno di loro funzionava e all'altro no. E' venuto fuori che
> praticamente avevano scelto la stessa password e il sistema, che aveva
> fatto andare avanti il primo di loro senza problemi, non faceva andare
> avanti il secondo, limitandosi a segnalare un generico errore. Quando il
> secondo ha scelto una password diversa dal primo il sistema non ha più
> protestato e ha fatto andare avanti anche il secondo.
>
> C'è un logica in tutto questo, visto che potrebbe capitare che due che
> non si conoscono scelgano la stessa password e in quel caso il secondo
> non va avanti e nessuno capisce perché ?
>
> Ciao,
> Marco.
>

scommetto che era lo spid POSTE.IT ?

infatti molti si incartano e affermano di non andare avanti...in realtà
cercano di accedere PRIMA DEI VENTI MINUTI che il sistema impiega ad
attivare l'account, per cui riprovano e riprovano, cambiano
password...insomma fanno casino gli utenti inventandosi poi strane
regole ....finchè il sistema li accetta ..

vitorio

unread,

Aug 6, 2021, 9:52:26 AM8/6/21

to

Il 01/08/2021 11:35, Marcoxxx ha scritto:
> Il 30/07/2021 21:47, rootkit ha scritto:
>> On Fri, 30 Jul 2021 16:03:51 +0200, Marcoxxx wrote:
>>
>>
>
>> e anche l'idea che quell'errore fosse dovuto al fatto che avevano usato
>> la stessa password... cioè l'avessi verificato su due o tre casi poteva
>> al limite venire un vago sospetto c'entrasse qualcosa, ma *uno*...
>
>
> Mi spiego meglio: sono stati fatti 3-4 tentativi con l'utente che
> aveva tentato di usare la stessa password che aveva usato per sua moglie
> (*)
> in un intervallo di tempo di circa 30-40 minuti (proprio pensando che
> fosse un problema temporaneo era stato fatto qualche tentativo
> semplicemente "aspettando un po'"). Tutti i tentativi sono falliti con
> un generico "errore nei dati" o qualcosa del genere (ovviamente non mi
> ricordo la dicitura esatta).

ecco, SPID DI POSTE.IT ! hahahahah!

Dovevi aspettare la mail di conferma ATTIVAZIONE , che arriva in 5 min
ma anche in 50 min a seconda del server!

vitorio

unread,

Aug 6, 2021, 9:55:38 AM8/6/21

to

Il 30/07/2021 23:33, rootkit ha scritto:
> On Thu, 15 Jul 2021 12:55:17 +0200, Giangi72 wrote:
>
>
>> Bha, motivi non ne vedo e mi sembrerebbe strano, io non ho mai visto la
>> password come chiave, da sola o come conchiave insieme al nome utente.
>
> sarebbe una cosa priva di senso. primo, le password sono hashed: secondo,
> sono salted.

quindi quando digito username e password e clicco accedi, il server di
destinazione confronta la username con l'hash che ha memorizzato della
mia password?

Oppure la password che digito viene di nuovo hashata e salted?
Ma in tal caso come fa a generare lo stesso hash e confrontarlo??

Grazie

rootkit

unread,

Aug 6, 2021, 4:09:57 PM8/6/21

to

il salt non è segreto è salvato insieme all'hash della password.
conoscerlo non aiuta minimamente un brute force.

ma...@daqualcheparte.it

unread,

Aug 6, 2021, 6:35:21 PM8/6/21

to

On 06/08/21 22:09, rootkit wrote:

> il salt non è segreto è salvato insieme all'hash della password.
> conoscerlo non aiuta minimamente un brute force.

Diciamo che non è del tutto vero.

Prima chiariamogli la ragione del sale e perché il hash non basta.
I criminali hanno già i DB pieni di parole segrete più note ("qwerty",
"123456", "password",...) e quelle specifiche per un certo ambiente
geografico, politico o altro ("juventus", "forzamilan",...,
"beppegrillo" (scusate la parolaccia!), ecc. E per ciascuna di queste
parole o frasi "segrete", hanno (già pronti, generati in anticipo) gli
hash creati utilizzando tutti gli algoritmi principali.

Un'altra premessa di dovere (non direttamente correlata al problema del
quele si discute qui, ma in certi casi può anche essere rilevante) è che
spesso la gente utilizza le stesse credenziali per diversi servizi. Così
se uno gli scopre le loro credenziali per la casella di posta
elettronica, ci sono delle probabilità più che discrete che abbiano
scoperto come autenticarsi a tutti i servizi da loro sottoscritti. Anche
se ti può sembrare da stolti fare questo tipo di errore, ti assicuro che
in molti lo fanno, per semplice pigrizia (e si, anche stoltezza). Fin
qui, è chiaro? Procediamo...

Dunque, se un hash (tuo) corrisponde a un hash noto (generato da una
parola segreta nota (a te, ma troppo comune, utilizzata da molti, es.
"qwerty"), con un algoritmo noto (ai programmatori e/o sistemisti del
servizio al quale ti sei registrato, ma abbastanza facilmente
identificabile dai malintenzionati), questi ultimi hanno scoperto anche
il dato che volevano scoprire, perche la corrispondenza è 1:1 (si, ci
sono possibilità teoriche di collisione, ma sorvoliamole perché
irrilevanti ai fini di questa spiegazione). A patto che mettano le mani
sui dati hashati (e sul DB), ovviamente, o a una delle copie di questi,
ma è proprio di questo che stiamo parlando.

Ma, la parola segreta, con un sale scelto a caso (che può anche essere
pubblico) grazie allo stesso algoritmo di prima, ora genera un codice
hash-ato non comune e non prevedibile (perché frutto della scelta a
caso, appunto!), e non presente nelle basi di dati dei criminali (o
delle multinazionali canaglia o dei governi canaglia).

La tua parola segreta, con il sale noto, e l'algoritmo noto, producono
ogni volta lo stesso risultato che aiuta a te ad autenticarti e rende
difficile ai malintenzionati di carpire i tuoi dati segreti perché tu ce
la fai ad autenticarti senza che nessuno conosca la tua parola segreta
(tranne te). E da tener conto che non fanno più il hash della tua parola
segreta da sola (un dato), ma di una coppia di dati (la tua parola
segreta + il sale => due dati dati in pasto all'algoritmo di hashing).
Dunque, le tabelle del DB menzionato prima diventano inutili.

Dunque, se è vero (ed è vero!) che non è possibile (ma vedi la parentesi
di sotto) fare una scansione di un DB trafugato o "bucato", di (per
esempio) 60 milioni di utenti e scoprire che 20% di loro hanno
utilizzato una delle parole segrete "incriminate" scritte sopra, questo
non significa che siamo in una botte di ferro.

Ed è qui viene il (potenziale) problema. Se qualcuno vuole scoprire tra
quei 60 milioni le credenzali *TUE* (per motivi specifici, che ne so,
sei un dissidente politico, o uno scienziato che è sul punto di
brevettare una nuova cura contro il cancro, o un criminale, o sei un
giudice che indaga su qualche personaggio colluso con dei giri
"diversamente onesti", o sei un politico del quale bisogna scoprire i
panni sporchi per "convincerlo" a votare in un certo modo (cose per
niente fantapolitiche, già 8 anni fa Snowden le aveva esposte!), ci sono
- dunque - vari potenziali bersagli e varie motivazioni di quelli che
potrebbero prenderti come bersaglio, i potenziali vettori d'attacco sono
molteplici, e il lavoro di quella gentaglia non è sempre così difficile
come può sembrare.

Dunque, tu sei controllato, profilato, intercettato, per il solo fatto
che utilizzi certi dispositivi di comunicazione, navighi sui certi siti
(sportivi, politici, erotici, religiosi, gastronomici, ecc), il tuo
cellulare ti origlia continuamente perché lo hai autorizzato tu (se ci
fai il caso, non ti chiede mai: "Vuoi consentire l'accesso di questa app
al microfono durante il tuo utilizzo del nostro servizio?" Ti chiede
solo la metà di questa domanda. Le ragioni ti dovrebbero ormai essere
chiare. Ci sono aziende che sanno quante volte vai sul cesso e quanti
peli hai sul fondoschiena. La tua banca sa che la tua azienda naviga
nelle cattive acque e puoi socrdarti il mutuo per la casa. Sanno che
regolarmente compri quella mozarella alla diossina, mangi cibo
spazzatura, bevi, fumi, non sei iscritto in nessuna palestra, dormi poco
e irregolarmente (dati che valgono oro per compagnie assicurative!). E
tra tutto questo, diventa facile preconfezionare qualche collagamento in
rete, presentarlo a te ed essere sicuri che tu ci vai su quel sito (e
che ti registrerai)!

Benissimo (si fa per dire). Faccio perè qui un'altra piccola premessa,
come digressione (e correlata solo indirettamente e lateralmente), prima
di arrivare al punto. Se ti sei registrato su uno di questi siti (e il
sistema lo sa, perché ti segue), e sei stato abbastanza sprovveduto da
utilizzare le stesse credenziali, attaccano prima quel server (più
plausibile che quello abbia le politiche di sicurezza meno restrittive),
e può anche essere un server messo in piedi apposta come "esca", e il
gioco è fatto. Si potrebbe dire "Fine digressione" se non fosse che
alcuni grandi nomi dei servizi di rete registrano i tuoi dati *anche* in
chiaro magari su un DB diverso) e anche tutti i tuoi tentativi di
accesso, anche quelli errati (immagina che per distrazione tu abbia
digitato sul sito del tuo superfigomediasociale la chiave segreta che
usi per criptare la partizione di sistema del tuo computer di casa con
LUKS 2. Non sia mai che a questo supermegafigomediasociale si rivolgano
le forze dell'ordine (con moneta sonante) per ottenere informazione che
hanno sul tuo conto perché devono ispezionare il tuo computer. Magari tu
non sei un bersaglio tipico per le forze dell'ordine e te ne frega poco,
ma se tu fossi un dissidente politico in un regime dove è reato quello
che nel tuo paese non è reato, ragioneresti diversamente.
Comunque, per i grandi nomi della "economia di sorveglianza" una persona
è come un maiale: Non si butta via niente.
Sai dove voglio arrivare, dunque inutile che procedo. Vale la pena solo
menzionare che tutte queste credenziali "qualcuno" le memorizza, magari
non servono, e forse non serviranno mai, ma non si sa mai quando
potrebbero servire ed essere "monetizzate". Fine parentesi.

Supponiamo ora, però, che quello non è successo. Sei molto savio e
circospetto e non hai fatto nessuno di quegli errori. E non si tratta di
un tuo PC di casa ma di un servizio (o diciamo più di uno) ai quali
accedi regolarmente e che si trova fuori dalla giurisdizione italiana in
un paese che notoriamente risponde sempre picche alle forze dell'ordine
dei paesi europei. Queste devono, dunque, gettare la spugna? No.
ovviamente.

Se trovano un modo di bucare quel server lì (e la guerra cibernetica, ti
sarà noto, è in atto da decenni, 24 ore/24, 365 gg/anno), e se
carpiscono i tuoi dati hashati e il sale, creeranno una tabella di tutte
quelle parole "incriminate" di sopra, unite alle tue parole segrete che
hanno carpito da altre parti (per questo la mia premessa di sopra che ho
detto correlata solo lateralmente, ma adesso dovrebbe essere chiaro che
è, eccome, correlata) con il tuo sale e cercheranno di ricavare la tua
parola segreta (utilizzando la forza bruta!). Per potersi poi collegare
a volontà (e a tua insaputa) a quel servizio. Di conseguenza: Se
utilizzare la parola "qwerty" o "123456" è stato il tuo unico errore che
hai fatto, quell'errore ti potrebbe comunque costare caro.

Ora devo anche scrivere la parentesi promessa sopra: Non darei per
scontato che la cosa non sia possibile fare (e che non sia fatta
regolarmente) anche sui dati con 60 milioni di record per 60 milioni di
utenti. Quanta potenza di calcolo ci potrebbe volere? E' sufficente
qualla delle botnet gestite dai criminali? O, per esmepio, comprando una
certa potenza di calcolo su AWS o un'altra "nuvola"? Non lo so, non ho
la minima idea (e non ho energie per cervellare a quest'ora), è solo una
congettura che non me la sento di escludere.

Per questo ripeto: Non sei mai in una botte di ferro. E non dare mai
niente per socntato. MAI!

Scusate, sono arrivato alla fine del messaggio, ma sono troppo cotto per
rileggerlo. Ci saranno di sicuro errori, ma vi chiedo di non
rinfacciarmeli. Vado a nanna, se no Google registrerà che dormo poco, e
quando avranno smantellato l'INPS e arrivano le assicurazioni amerciane
sono fregato. :-P

rootkit

unread,

Aug 21, 2021, 3:30:06 PM8/21/21

to

On Sat, 07 Aug 2021 00:35:17 +0200, ma...@daqualcheparte.it wrote:

[...]

perdonami se cutto tutto ma era effettivamente tanto.

faccio io una premessa doverosa: il salt *non* protegge dal brute force,
ma dal rainbow talbe attack.
quando dico che conoscere il salt non aiuta il brute force mi baso su un
semplice ragionamento. supponiamo che tu abbia due hash di una password
comune, es. "qwerty", una non saltata e una saltata con la stringa
"abcdefghi"; questo vuol dire che la prima sarà "qwerty" e la seconda
"abcdefghiqwerty". se vuoi attaccarla di forza bruta conoscere il
prefisso cosa ti cambia in termini di numero di tentativi? ovviamente
nulla. però ti cambia in termini di costo per tentativo, perché calcolare
l'hash di una chiave di 5 caratteri è molto più veloce rispetto a
calcolare l'hash di una chiave di 15 caratteri, e anche se i primi 10 li
conosci non puoi mica escluderli dal calcolo. considerato poi che gli
algoritmi prevedono un numero variabile di iterazioni e che queste
moltiplicano il tempo cpu necessario al calcolo, va da se che la
progressione del tempo cpu col numero di bit della chiave può essere
anche abbastanza ripida (anche se ovviamente per ragioni pratiche non si
può rallentare più di tanto).

chiaramente se la tua contestazione è che il salt non rende una password
debole più forte ti rispondo grazie al piffero :-) non è questo il suo
scopo. o meglio, protegge le password dall'attacco rainbow table, che non
è tutto ma se permetti neanche poco.

Marcoxxx

unread,

Aug 21, 2021, 4:11:47 PM8/21/21

to

Chi ha mai parlato di "cercare di accedere" ?

vitorio

unread,

Aug 24, 2021, 6:16:07 PM8/24/21

to

Il 21/08/2021 22:11, Marcoxxx ha scritto:

> Chi ha mai parlato di "cercare di accedere" ?
>

"l'attivazione dello SPID ad uno di loro funzionava e all'altro no. "

Non riuscendo ad accedere cambia la password , poi riprova, poi
ricambia, poi ti dice che hai fatto già tre tentativi etc...Poi clicca
su ho dimenticato la pwd etc...

A volte il sistema ti accetta dopo 2 minuti, altre dopo 20 minuti !

Dai, ci sei cascato con le scarpe!

PS: faccio assistenza ai caf, metà dei clienti fai date si è incartata
nello stesso punto, le poste si sono DIMENTICATE DI MANDARE UN MSG
DICENDO di ASPETTARE e non accedere subito!

rail

unread,

Aug 25, 2021, 4:13:12 AM8/25/21

to

Il 21/08/2021 22:11, Marcoxxx ha scritto:

>

> Chi ha mai parlato di "cercare di accedere" ?
>

Che pagliaccio che sei!

Marcoxxx

unread,

Aug 27, 2021, 7:08:03 AM8/27/21

to

Il 25/08/2021 00.16, vitorio ha scritto:
> Il 21/08/2021 22:11, Marcoxxx ha scritto:
>
>> Chi ha mai parlato di "cercare di accedere" ?
>>
>
> "l'attivazione dello SPID ad uno di loro funzionava e all'altro no. "
>

Appunto. L'attivazione dello spid. Non l'accesso (che non si può fare
fino a quando lo spid non è attivato)

> Non riuscendo ad accedere

ACCEDERE A COSA ?

Non riuscendo ad ATTIVARE.
Ti è chiara la differenza tra ACCEDERE e ATTIVARE o no ?

Ciao,
Marco

Marcoxxx

unread,

Aug 27, 2021, 9:29:40 AM8/27/21

to

Toh. Mi ricordi una "faina" che si aggirava qui tempo fa, con altri
nickname. Non so tu sia lo stesso (non controllo gli ip), ma a mio
avviso hai molto in comune con la suddetta "faina". Come minimo avete
in comune il fatto di essere finiti nei miei filtri.
Sfortunatamente fino a fine mese mi tocca andare senza filtri per
cui oggi vedo anche i tuoi post. Con anticipo di una settimana (ma
anche meno) ti auguro un buon ritorno in quello che, secondo me, è il
tuo "deserved place".

Ciao,
Marco.

rail

unread,

Aug 27, 2021, 10:04:24 AM8/27/21

to

Il 27/08/2021 15:29, Marcoxxx ha scritto:
> Il 25/08/2021 10.13, rail ha scritto:
>> Il 21/08/2021 22:11, Marcoxxx ha scritto:
>>
>>>
>>> Chi ha mai parlato di "cercare di accedere" ?
>>>
>>
>> Che pagliaccio che sei!
>>
>
> Toh.