dacstoken: online nel cloud

PROGRAMMA:

NOME

dacstoken: amministra password monouso basate su hash

SINOSSI

dacstoken [dacoptions[1]] [-tutti] [-base num] [-contatore num] [-cifre num]
[-disattivare | -abilitare] [-finestra hotp num] [-inkeys tipo di elemento]
[[-chiave keyval] | [-file-chiave Nome del file] | [-richiesta chiave,-modalità modalità otp]
[-outkey tipo di elemento]
[[-Pin pinval] | [-file-pin Nome del file] | [-richiesta pin,-vincoli dei pin str]
[-rnd] [semi str] [-seriale str] [-totp-delta num] [-totp-deriva nwindows]
[-totp-hash alg]
[-totp-timestep secs] [-vfs vfs_uri] [spec] [nome utente]

DESCRIZIONE

Questo programma fa parte di DACS on.

I dacstoken l'utilità amministra DACS account associati a password monouso (OTP)
dispositivi di generazione (token) o client basati su software. Utilizzando le opzioni della riga di comando, anche
calcola i valori OTP; I parametri dell'account token possono essere sovrascritti, ma gli account non lo sono
richiesto.

È possibile fornire un'autenticazione forte a due fattori quando dacs_autenticate[2] è configurato
per utilizzare il local_token_authenticate[3] modulo di autenticazione o quando dacstoken è usato come
un programma autonomo per convalidare le password. Sia la modalità password monouso basata su HMAC
(HOTP), basato su un contatore di eventi e specificato da RFC 4226[4] e quello basato sul tempo
modalità password monouso (TOTP), come specificato dal con i più recenti IETF Bozza Internet[5] proposta,
sono supportati. aggiuntivo operativa modalità di[6] denominato OCRA (GIURAMENTO Sfida-Risposta
Algoritmi), descritti in un IETF Internet-Draft, non sono ancora completamente supportati.

Note:
Questa versione di dacstoken incorpora molte modifiche che non sono compatibili con le versioni precedenti
con la versione 1.4.24a e precedenti. Alcuni flag della riga di comando funzionano in modo diverso e
il formato del file dell'account è cambiato. Se hai utilizzato questo comando in precedenza
versioni, fai una copia di backup del file del tuo account token e consulta questo manuale
pagina attentamente prima di procedere (notare il -convertire flag[7] in particolare).

Consigli
Non è richiesto alcun software fornito dal fornitore dacstoken per fornire la sua funzionalità. IL
i dispositivi attualmente supportati non necessitano di alcuna registrazione o interazione di configurazione
con i venditori e dacstoken effettua non interagire con venditori server or uso in qualsiasi
proprio Software. Per l'esecuzione potrebbe essere necessario il software fornito dal fornitore
inizializzazione o configurazione per altri dispositivi token, tuttavia, e dacstoken effettua
non fornire loro tale supporto.

Ogni dispositivo token corrisponde generalmente esattamente a un account gestito da
dacstoken, sebbene alcuni fornitori producano token in grado di supportare più account.

Per riassumere, questa utilità:

· crea e amministra DACS account associati a contatore e a tempo
password monouso

· fornisce funzionalità di convalida e test

· fornisce una funzionalità di autenticazione della riga di comando

Sicurezza
Solo il DACS l'amministratore dovrebbe essere in grado di eseguire correttamente questo programma dal
riga di comando. Perché DACS chiavi e file di configurazione, incluso il file utilizzato per
account del negozio, deve essere limitato all'amministratore, questo sarà normalmente il
caso, ma un amministratore attento imposterà i permessi dei file per negare l'accesso a tutti
altri utenti.

Note:
I dacs_token(8)[8] Il servizio web fornisce agli utenti un servizio self-service limitato
funzionalità per impostare o reimpostare il PIN dell'account e sincronizzare il token. Anche
ha una modalità dimostrativa per semplificare i test e la valutazione.

PIN (Account Le password)
A dacstoken all'account può facoltativamente essere associato un PIN (ovvero una password). A
autenticarsi con tale account, un utente deve fornire la password monouso prodotta
dal gettone ed Il pin. IL TOKEN_REQUIRES_PIN[9] la direttiva di configurazione determina
se è necessario fornire un PIN durante la creazione o l'importazione di un account; non si applica in
congiunzione con il -delpin flag, poiché solo un amministratore dovrebbe essere in grado di eseguire
quella funzione.

Nel record dell'account viene archiviato un hash del PIN anziché il PIN stesso. Lo stesso
metodo utilizzato da dacspasswd(1)[10] e dacs_passwd(8)[11] viene applicato e dipende da
PASSWORD_DIGEST[12] e PASSWORD_SALT_PREFIX[13] direttive in vigore. Se
PASSWORD_DIGEST[12] è configurato, viene utilizzato quell'algoritmo, altrimenti un file in fase di compilazione
viene utilizzato il valore predefinito (SHA1). Se un utente dimentica il PIN, quello vecchio non potrà più essere recuperato
deve essere cancellato oppure è necessario impostarne uno nuovo.

Alcuni dispositivi token dispongono di funzionalità PIN incorporata. L'utente deve inserire un PIN in
il dispositivo prima che il dispositivo emetta una password monouso. Questo "PIN del dispositivo" è
completamente distinto dal PIN dell'account gestito da dacstoken, e questo manuale è
interessato solo al dacstoken SPILLO. Il PIN del dispositivo va sempre utilizzato quando possibile;
, il dacstoken Il PIN è fortemente consigliato ed è richiesto per l'autenticazione a due fattori
(a meno che non venga applicato un ulteriore fattore di autenticazione in qualche altro modo).

Poiché solo l'amministratore può eseguire questo comando, non viene imposta alcuna restrizione
dalla lunghezza o qualità dei PIN forniti dall'amministratore; un messaggio di avviso
verrà emessa, tuttavia, se la password è considerata debole come stabilito dal
PASSWORD_VINCOLI[14] direttiva.

Una volta Le password
Entrambi i tipi di dispositivi con password monouso calcolano il valore della password utilizzando un metodo sicuro
algoritmo hash con chiave (RFC 2104[15], FIP 198[16]). Nel metodo basato sul contatore, il dispositivo
e il server condividono una chiave segreta e un controvalore che vengono sottoposti ad hashing per produrre un valore numerico
valore visualizzato in una certa radice con un certo numero di cifre. Riuscito
l'autenticazione richiede che il dispositivo e il server calcolino le password corrispondenti. Ogni volta che
dispositivo produce una password, incrementa il suo contatore. Quando il server riceve una corrispondenza
password, incrementa il suo contatore. Perché è possibile che i due contatori diventino
non sincronizzato, l'algoritmo di corrispondenza del server in genere consentirà la password di un client
rientrare in una "finestra" di controvalori. Il metodo basato sul tempo è simile, il principale
la differenza è che l'ora Unix corrente (come restituita da tempo(3)[17], per esempio) lo è
utilizzato per stabilire una "finestra temporale" che funge da controvalore nel calcolo
dell'hash sicuro. Perché gli orologi in tempo reale sul dispositivo e sul server potrebbero non esserlo
sufficientemente sincronizzato, l'algoritmo di corrispondenza del server deve consentire anche quello del client
la password deve rientrare in un certo numero di finestre di fasi temporali per questi dispositivi.

Sicurezza
A un token può essere assegnata una chiave segreta permanente (a volte chiamata seed OTP).
produttore o la chiave può essere programmabile. Questa chiave segreta viene utilizzata dai token
procedura di generazione della password ed è fondamentale che sia mantenuta privata. Se il gettone
non è programmabile, la chiave viene ottenuta dal fornitore (per un token HOTP, in genere
fornendo il numero di serie del dispositivo e tre eventuali password consecutive). Un record
di ogni mappatura dal numero di serie alla chiave segreta deve essere conservato in un luogo sicuro.

Se la chiave segreta è programmabile, come è probabile che accada con un client software, lo è
richiesto di essere almeno 128 pezzi di lunghezza; un minimo di 160 bit è raccomandato. Il
La chiave è rappresentata da una stringa esadecimale lunga 16 (o più) caratteri. La chiave dovrebbe
essere ottenuto da una fonte di qualità crittografica di bit casuali. Alcuni clienti potrebbero esserlo
in grado di generare una chiave adatta, ma è possibile utilizzare dacspr(1)[18]:

% dacsexpr -e "casuale(stringa, 20)"
"bb2504780e8075a49bd88891b228fc7216ac18d9"

Consiglio
I token possono essere utilizzati per scopi di autenticazione diversi dall'accesso al computer. Per
Ad esempio, fornendo un numero di conto, un PIN e un valore del token, i clienti possono farlo rapidamente
essere autenticato telefonicamente, riducendo o eliminando la necessità di costosi e
domande di sicurezza che richiedono molto tempo.

I dispositivi e le applicazioni con password monouso hanno i seguenti parametri operativi.
Questi parametri determinano la sequenza della password che viene generata. Alcuni operativi
i parametri possono essere fissati (dallo standard pertinente o a causa dell'implementazione), mentre
altri possono essere parzialmente o completamente configurabili dall'utente. Si prega di fare riferimento al
riferimenti e documentazione del produttore per i dettagli.

base
La radice in cui vengono visualizzate le password.

contrastare
Solo per la modalità HOTP, il valore del contatore corrente.

cifre
Il numero di cifre in ciascuna password monouso.

chiave
La chiave segreta (seme OTP).

numero di serie
Un identificatore o nome univoco per il dispositivo.

dimensione del passo temporale
Solo per la modalità TOTP, l'ampiezza di ciascun intervallo di tempo, in secondi. La stessa parola d'ordine
verrà generato entro un dato intervallo; cioè, questa è la "durata" o validità
periodo di ciascuna password TOTP.

Oltre a questi parametri, dacstoken ne impiega diversi per account (ovvero per dispositivo)
parametri:

finestra di accettazione
Quando si convalida una password HOTP, il numero massimo di password da considerare dopo il
password prevista.

deriva
Solo per la modalità TOTP, il numero di secondi in base ai quali regolare l'orologio del server
avanti o indietro per sincronizzarlo meglio con il dispositivo. Questo è abituato
compensare token o software client i cui orologi non sono ben sincronizzati
quello del server.

finestra alla deriva
Solo per la modalità TOTP, ma analogamente alla finestra di accettazione, il numero massimo di
intervalli (ciascuno della dimensione del passo temporale) per la ricerca avanti e indietro durante la convalida
contro una determinata password.

sync-opps
Solo per la modalità HOTP, il numero di password monouso consecutive richieste
sincronizzare l'account con il dispositivo.

nome utente
Il nome del DACS account associato al dispositivo.

L'autenticazione basata su dispositivi con password monouso presenta i seguenti vantaggi:

· Ogni volta che un utente si autentica, verrà generata una password diversa (con valore alto
probabilità); gli utenti non possono quindi annotare "la password" perché la password lo è
sempre in cambiamento; gli utenti non possono dimenticare la propria password;

· Una volta utilizzata, la password in modalità HOTP viene immediatamente "consumata" ed è improbabile che venga utilizzata
ancora per molto tempo; con opportuni parametri di configurazione, una password per la modalità TOTP
"scade" automaticamente entro un intervallo di tempo relativamente breve ed è improbabile che lo sia
usato di nuovo per molto tempo;

· Se non è richiesta alcuna correzione per la deriva dell'orologio, un account in modalità TOTP può essere di sola lettura
funzionamento;

· Poiché è improbabile che la password sia un numero o una stringa facilmente indovinabile, dovrebbe esserlo
essere più forte della maggior parte delle password selezionate dall'utente;

· Un token HOTP può essere la base di un metodo di autenticazione reciproca (“bidirezionale”); IL
il server mostra all'utente la password successiva del suo token per confermarne l'identità (con entrambi
parti che avanzano i loro contatori), quindi il client mostra al server la password successiva
confermare la sua identità;

· Se sul computer dell'utente è installato uno sniffer di chiavi, una password sniffata non lo fa
fare del bene a un attaccante a meno che a man-in-the-middle attacco[19] è possibile; dato N
password consecutive è ancora molto difficile calcolare la password N + 1 senza
conoscere la chiave segreta;

· È più difficile per gli utenti condividere un account (anche se a volte gli utenti potrebbero
considerarlo un inconveniente);

· Se un dacstoken Il PIN viene assegnato a un account e un utente malintenzionato ottiene quello dell'account
token, è ancora difficile per l'attaccante autenticarsi senza conoscere il PIN;

· Un modo rapido ed immediatamente efficace per disattivare un account è semplicemente impossessarsi di a
token hardware (ad esempio, se un dipendente viene licenziato), sebbene un account possa essere disabilitato tramite
questo programma o utilizzando il revoca stratagemma[20];

· Nel caso di un client software che viene eseguito su un dispositivo mobile, come un telefono o un PDA,
gli utenti stanno già portando con sé il dispositivo; sono disponibili client gratuiti, quindi ecco
potrebbe non esserci alcun costo aggiuntivo (tieni presente che i dispositivi mobili potrebbero non offrire lo stesso
resistenza alla manomissione, durabilità, segretezza della chiave, precisione dell'orologio, ecc. di un token hardware).

I dispositivi con password monouso presentano i seguenti potenziali svantaggi:

· È prevista una spesa una tantum per un token hardware (a seconda del volume di acquisto,
puoi aspettarti di pagare $ 10- $ 100 USD ciascuno) e c'è la possibilità di doverlo fare
sostituire un gettone perso o rotto o la batteria di un gettone (alcune unità hanno un
batteria non sostituibile, rendendoli usa e getta dopo qualche anno);

· La configurazione iniziale è un po' più difficile rispetto ad altre autenticazioni
metodi e gli utenti che non hanno familiarità con i dispositivi dovranno essere istruiti sui propri
uso;

· Anche se in genere sono piuttosto piccoli (ad esempio, 5 cm x 2 cm x 1 cm) e possono essere attaccati
un portachiavi o un cordino, o tenuti in un portafoglio, gli utenti potrebbero sussultare nel dover portare con sé un gettone
in giro con loro;

· Gli utenti possono dimenticare di avere con sé il proprio token o perderlo;

· Un dispositivo mobile (con un client software) è probabilmente un probabile bersaglio di furto, anzi
quindi un token hardware (da qui l'importanza aggiuntiva di un PIN per questo dispositivo);

· A differenza di un token hardware in cui la chiave viene impressa in modo inaccessibile e a prova di manomissione
memoria, è probabile che la chiave configurata in un client software sia leggibile dal suo
proprietario, rendendo possibile la condivisione dell'account;

· L'immissione di un valore seed di 40 caratteri o più in un dispositivo mobile può essere frustrante
e incline all'errore;

· Una volta che un dispositivo TOTP genera una password, non è possibile generare una nuova password finché non viene
finestra del passaggio temporale successivo, che richiede all'utente di attendere 30 (o eventualmente 60) secondi (ad esempio,
se viene commesso un errore di inserimento);

· Alcuni dispositivi sono difficili da leggere in condizioni di scarsa illuminazione; utenti presbiti e simili
con problemi di vista potrebbero avere difficoltà a leggere il display.

conti
I conti gestiti da dacstoken sono completamente separati dagli account utilizzati da
local_passwd_autenticate[21] o qualsiasi altro DACS modulo di autenticazione.

Gli account per i dispositivi HOTP e TOTP possono essere combinati o tenuti separati. Se il virtuale
il tipo di elemento filestore auth_hotp_token è definito, viene utilizzato solo per gli account associati
con token HOTP. Allo stesso modo, se il tipo di elemento dell'archivio file virtuale è auth_totp_token
definito, viene utilizzato solo per gli account associati ai token TOTP. Se uno dei due tipi di elemento lo è
non definito, si accede agli account tramite DACS archivio file virtuale utilizzando il tipo di elemento
token_autenticazione. Si presuppone che le autorizzazioni dei file sui database degli account siano tali che all
l'accesso è limitato all'amministratore e local_token_authenticate.

Se gli account per i due tipi di dispositivo sono combinato, perché ogni nome utente per un
il metodo di autenticazione deve essere univoco, se un individuo ha entrambi i tipi di token deve farlo
essere assegnati nomi utente diversi. Quindi, ad esempio, se Auggie ha un token HOTP e uno
TOTP, il primo potrebbe corrispondere al nome utente auggie-hotp e il secondo a
auggie-top; il modulo di accesso potrebbe includere un input in modalità dispositivo che consentirebbe ad Auggie
per digitare semplicemente "auggie" nel campo del nome utente e JavaScript per aggiungere automaticamente il file
suffisso appropriato in base alla modalità del dispositivo selezionato. Uno svantaggio evidente di questo
configurazione è che risulta in due diversi DACS identità per lo stesso individuo;
questo dovrebbe essere ricordato se fosse necessaria una regola di controllo degli accessi per identificare Auggie
esplicitamente. Se entrambi i token devono corrispondere allo stesso DACS identità, la clausola Auth potrebbe
rimuovere il suffisso dopo l'autenticazione riuscita, ma l'amministratore lo farebbe
è necessario fare attenzione al caso di due Auggies diversi, ciascuno dei quali utilizza un tipo di dispositivo diverso.

Configurare entrambi i tipi di elemento auth_hotp_token e auth_totp_token (o solo uno di essi
e auth_token) mantiene gli account separati e consente di utilizzare lo stesso nome utente
entrambi i tipi di dispositivi. Auggie potrebbe quindi avere un conto con lo stesso
nome utente per entrambi i tipi di dispositivo. Questo approccio richiede che sia specificata la modalità del dispositivo
quando viene richiesta un'operazione per poter utilizzare il tipo di elemento corretto; ciò significa che
l'utente deve sapere che tipo di dispositivo sta utilizzando (magari apponendo un'etichetta sullo stesso).
Fare riferimento a dettagli importanti riguardanti DACS identità[22].

I -vfs viene utilizzato per configurare o riconfigurare il tipo di elemento auth_token.

Solo le chiavi che soddisfano i requisiti di lunghezza minima della chiave (16 byte) possono essere memorizzati con
informazioni sull'account (ad esempio, con -impostato or -importare). In altri contesti, il requisito è
non imposto.

La chiave segreta è crittografata da dacstoken quando viene scritto nel file dell'account. IL
il tipo di elemento dell'archivio file virtuale auth_token_keys identifica le chiavi di crittografia per dacstoken
usare; IL -inkeys ed -outkey i flag specificano alternative (vedi chiavetta(1)[23]). Se la
le chiavi di crittografia vengono perse, le chiavi segrete sono praticamente irrecuperabili.

Consigli
Se un utente malintenzionato scopre una chiave segreta, genera password utilizzabili senza possederla
il token non sarà difficile. Per almeno alcuni token hardware, la chiave viene masterizzata
nel dispositivo e non può essere modificato; in questo caso, se la chiave perde il dispositivo
dovrebbe essere distrutto. Se un token viene perso, l'account corrispondente dovrebbe essere disabilitato.
Nel caso in cui un attaccante trovi un gettone smarrito o scopra una chiave segreta, avente un valore forte
Il PIN associato all'account renderà difficile l'ottenimento da parte dell'aggressore
accesso.

Consigli
· Questo metodo di autenticazione è stato testato rispetto ai seguenti prodotti OTP:

· Autentico Una chiave 3600[24] token hardware con password monouso (HOTP);

· Feitiano Tecnologie[25] Hardware con password monouso OTP C100 e OTP C200
gettoni, forniti da HyperSecu Informazioni SISTEMI DI TRATTAMENTO[26]; e

· GIURAMENTO Token[27] applicazione software di Archie Cobbs, che implementa entrambi
HOTP e TOTP sul iPod toccare, i phone, ed iPad[28].

· Tecnologie Feitian GIURAMENTO Light[29] Applicazione software HOTP per l'iPod
Tocca, iPhone e iPad.

Altri produttori interessati al supporto dei loro prodotti DACS sono
non esitare a contattare il Dss.

· Foto[30]: Feitian OTP C200, iPod Touch con l'app OATH Token, Authenex A-Key
3600 (in senso orario da in alto a sinistra)

· Sebbene questa implementazione dovrebbe funzionare solo con prodotti simili e conformi
questi prodotti sono ufficialmente supportati da DACS.

· I token hardware possono essere acquistati direttamente dai venditori.

· Eventuali problemi con l'utilizzo dei token per l'autenticazione DACS non sono il
responsabilità del venditore di token.

Importazione ed Esportazione OTP conti
Le descrizioni degli account e dei relativi token possono essere caricate o scaricate (fare riferimento al file -importare
ed -esportare bandiere). Ciò semplifica il provisioning di massa, il backup e la portabilità. IL
le informazioni sull'account sono scritte in un formato semplice, specifico dell'applicazione (quasi) XML.

Il formato compreso da dacstoken è costituito da un elemento root ("otp_tokens"), seguito da
zero o più elementi "otp_token", uno per riga, ciascuno con obbligatori e facoltativi
attributi (descritti di seguito). La dichiarazione XML deve essere omessa. Spazio bianco iniziale e
le righe vuote vengono ignorate, così come i commenti XML a riga singola. Inoltre, le righe con un "#"
poiché il primo carattere diverso dallo spazio viene ignorato. Attributi facoltativi che non lo sono
presenti vengono assegnati valori predefiniti. L'algoritmo digest predefinito è SHA1. Attributo breve
i nomi vengono utilizzati per risparmiare spazio. Attributi non riconosciuti e attributi irrilevanti per il file
modalità dispositivo, vengono ignorati. Caratteri di virgolette singole o doppie (o entrambi) all'interno dell'attributo XML
i valori devono essere sostituiti dal riferimento all'entità corrispondente ("'" e """,
rispettivamente), così come i caratteri "" (maggiore
il carattere than) può facoltativamente essere sostituito da un ">" sequenza, ma nessun'altra entità
si riconoscono referenze.

Gli attributi riconosciuti sono:

· B:
base
-- radice per il valore OTP
[Opzionale:
10 (Impostazione predefinita),
16, o 32]

· C:
contrastare
-- valore del contatore corrente per HOTP, in esadecimale se preceduto
per "0x" (o "0X"), altrimenti decimale
[Opzionale:
l'impostazione predefinita è 0]

· D:
OTP dispositivo modo
-- "c" (per HOTP)
o "t" (per TOTP)
[Necessario]

· dn:
nome-digest
- uno degli algoritmi hash sicuri
[Opzionale:
SHA1 (predefinito),
SHA224, SHA256,
SHA384, SHA512]

· dottor:
deriva dell'orologio
-- regolazione dell'orologio, in secondi, per TOTP
[Opzionale]

· ek:
chiave crittografata
-- chiave segreta crittografata, codificata base 64
[Necessario:
Solo record dell'account OTP]

· it:
stato abilitato
-- 1 per abilitato,
0 per disabili
[Necessario]

· K:
chiave di testo in chiaro
- chiave segreta non crittografata
[Necessario]

· lu:
ultimo aggiornamento
-- Ora Unix dell'ultimo aggiornamento del record
[Facoltativo: l'impostazione predefinita è l'ora corrente]

· nd:
cifre
-- numero di cifre per il valore OTP
[Opzionale:
l'impostazione predefinita è 6 per HOTP,
8 per TOTP]

· P:
PIN in testo normale
-- Valore PIN in testo normale per l'account
[Necessario:
a meno che il ph non sia presente,
solo per l'importazione]

· foto:
PIN con hash
-- Valore PIN con hash per l'account
[Opzionale:
generato da dacstoken
solo per file di account di esportazione e OTP]

· S:
numero di serie
-- stringa identificativa univoca per il dispositivo
[Necessario]

· ts:
passo temporale
-- valore del passo temporale, in secondi, per TOTP
[Opzionale:
l'impostazione predefinita è 30]

· tu:
nome utente
-- un valido DACS nome utente associato a questo account
[Necessario]

L'esempio seguente descrive due account che potrebbero essere creati utilizzando il file -importare bandiera:







Sicurezza
Poiché i record importati includono le chiavi segrete non crittografate per i dispositivi OTP, il file
il file esportato deve essere mantenuto crittografato (ad esempio, utilizzando OpenSSL) o almeno averlo
autorizzazioni file appropriate.

Note:
È in fase di sviluppo un formato standard per il provisioning dei dispositivi OTP. Questo formato potrebbe essere
compreso da una versione futura di dacstokenoppure è possibile scrivere un'utilità di conversione.
È probabile che il formato standard sia considerevolmente più complesso di quello DACS formato.

VERSIONI

Oltre allo standard dacoptions[1], è presente un lungo elenco di flag della riga di comando
riconosciuto. Quando un nome utente viene fornito, i valori predefiniti associati a tale account sono
utilizzato, altrimenti vengono utilizzati valori predefiniti consigliati o specifici dell'implementazione. Questi sono predefiniti
i valori possono solitamente essere sovrascritti dalla riga di comando. Alcuni flag sono consentiti solo con a
particolare modalità token (ad es. -contatore, -totp-mostra) e il loro aspetto implica che la modalità,
fare il -modalità contrassegnare non è necessario; altri flag sono indipendenti dalla modalità (ad esempio, -Elimina,
-abilitare). È un errore utilizzare una combinazione di flag reciprocamente incompatibili. Bandiere che sono
privi di significato con l'operazione selezionata vengono ignorati, anche se implicano comunque una modalità.
I valori esadecimali non fanno distinzione tra maiuscole e minuscole. Se un valore del contatore è richiesto ma non specificato
(ad esempio, quando si crea un account), viene utilizzato un controvalore iniziale pari a zero.

I spec specifica l'operazione da eseguire, insieme a zero o più modificatore
bandiere. Se spec manca, il -elenco viene eseguita l'operazione. UN spec è una delle
seguenti:

-aut valore-otp
Questa bandiera è come -convalidare[31], tranne:

· A nome utente è obbligatorio, da cui si ottengono tutti i parametri (come la chiave);

· se il conto è dotato di PIN, è necessario fornirlo;

· se l'account è per un token HOTP, il contatore verrà aggiornato in caso di autenticazione
ha successo

Uno stato di uscita pari a zero indica un'autenticazione riuscita, mentre qualsiasi altro valore
significa che l'autenticazione non è riuscita.

-convertire Nome del file
Carica un file account token in formato precedente (prima della versione 1.4.25). Nome del file ("-"
significa leggere da stdin), convertirlo nel formato più recente e scriverlo su stdout (come
by -esportare). Questo flag è deprecato e questa funzionalità verrà rimossa in futuro
rilascio di DACS.

-creare
Crea un account per nome utente, che non deve già esistere. Per altri aspetti lo è
funziona come -impostato[32]. Quando crei un nuovo account, -seriale è richiesto e -chiave is
implicito. Se no -abilitare il contrassegno viene fornito durante la creazione di un account, -disattivare è implicito.
Se no -contatore viene fornito il flag, viene utilizzato il valore predefinito pari a zero. Se uno dei flag PIN è
presente, all'account verrà assegnato il PIN indicato, altrimenti l'account no
disporre di un PIN (o il PIN esistente non verrà modificato).

-attuale
Visualizza il fattore di movimento corrente (ovvero il valore del contatore per HOTP o l'intervallo
valore per TOTP) e OTP previsto per nome utente. Per HOTP, il contatore è avanzato. Tutto
i parametri vengono presi dal conto.

-Elimina
Elimina l'account per nome utente. La chiave segreta del dispositivo e altre operazioni
i parametri andranno perduti.

-delpin
Eliminare il PIN, se presente, sull'account per nome utente, lasciando l'account senza a
SPILLO.

-esportare
Scrivi le informazioni su tutti gli account o, se possibile, su un solo account nome utente è dato, a
stdout. Se viene selezionata una modalità, tuttavia, lo saranno solo gli account che dispongono di quella modalità
scritto. Queste informazioni possono essere ricaricate utilizzando -importare or -importa-sostituisci. Il risultato
dovrebbero essere archiviati in forma crittografata o almeno avere i relativi permessi sui file
impostato in modo appropriato. Per esempio:

% dacstoken -uj ESEMPIO -export | openssl enc -aes-256-cbc > dacstoken-exported.enc

Successivamente, potresti fare qualcosa del tipo:

% openssl enc -d -aes-256-cbc < dacstoken-exported.enc | dacstoken -uj ESEMPIO -import -

-h
-Aiuto
Visualizza un messaggio di aiuto ed esci.

-hotp-show num
Dsiplay num password HOTP consecutive da un valore contatore e una chiave specificati. IL
-contatore flag può essere utilizzato per specificare un valore contatore iniziale. La chiave può essere
specificato usando -chiave, -file-chiave, o -richiesta chiave. Se una nome utente è fornito, il
il valore del contatore iniziale e la chiave vengono ottenuti dall'account HOTP dell'utente, a meno che uno dei due
il valore viene sovrascritto sulla riga di comando; il controvalore memorizzato nell'account non lo è
modificata. Questo è principalmente destinato a scopi di debug.

-importare Nome del file
-importa-sostituisci Nome del file
Carica le informazioni sull'account e sul token da Nome del file; Se Nome del file è "-", viene letto stdin.
Se viene selezionata una modalità, verranno letti solo gli account che dispongono di quella modalità. Con -importare è
un errore se esiste già un account importato e l'elaborazione si interrompe; -importa-sostituisci
sostituirà un account esistente con i dati importati.

-l
-elenco
-lungo
If nome utente viene fornito, visualizzare informazioni sull'account corrispondente; se la
-seriale viene fornito il flag, visualizza le informazioni sull'account con il seriale specificato
numero; altrimenti elenca tutti gli account. Se la -modalità flag viene fornito in uno qualsiasi di questi casi,
tuttavia, elenca solo gli account per cui è specificata la modalità operativa. Se questo
flag viene ripetuto, o con il -lungo flag, vengono visualizzati ulteriori dettagli: tipo di dispositivo,
stato dell'account, numero di serie del dispositivo, valore del contatore (per HOTP), valore di deriva dell'orologio (per
TOTP), se l'account dispone o meno di un PIN (indicato dal simbolo "+" o "-") e
l'ora e la data dell'ultima modifica dell'account.

-rinominare Nuovo nome utente
Rinominare l'account esistente per nome utente essere Nuovo nome utentee modificare il nuovo
account utilizzando argomenti della riga di comando (come con -impostato[32]). Poiché ciò richiede due passaggi
che non vengono eseguiti atomicamente, se si verifica un errore è possibile che il nuovo account lo faccia
essere creato e il vecchio account esisterà ancora.

-impostato
I -impostato flag viene utilizzato per modificare l'account esistente per nome utente sulla base di uno o più
argomenti di modifica (-base, -contatore, -cifre, -disattivare or -abilitare, -chiave (o -file-chiave
or -richiesta chiave), -Pin (o -file-pin or -richiesta pin), o -seriale). Anche la modalità può esserlo
modificato specificando -modalità, ma parametri specifici della modalità associati all'account
andrà perso (ad esempio, il valore corrente del contatore verrà eliminato se un account HOTP è
cambiato in un account TOTP) e i parametri generali (come il numero di serie) verranno modificati
mantenuto a meno che non venga sovrascritto dalla riga di comando.

-sincronizza elenco-password
In modalità HOTP, tenta di sincronizzare il server con il token per nome utente.
elenco-password è un elenco separato da virgole di tre password successive prodotte da
token dell'utente (questa funzione di "sincronizzazione automatica" è disponibile anche tramite
local_token_authenticate[3]). La sequenza data deve corrispondere alla sequenza calcolata
di preciso, visti i parametri operativi in ​​vigore; ad esempio, gli zeri iniziali sono
significativi, così come lo sono la radice del display e il numero di cifre OTP in vigore. Se
la sincronizzazione ha esito positivo, l'utente dovrebbe essere in grado di autenticarsi utilizzando il successivo
password prodotta dal dispositivo. Un algoritmo di ricerca esaustivo che utilizza l'aumento
vengono utilizzati i valori dei contatori, con un limite di tempo di compilazione sul numero massimo di
calcoli. La ricerca inizia dal valore del contatore attualmente memorizzato nel server, a meno che
uno viene fornito utilizzando -contatore. Se non dovesse avere esito positivo, l'operazione potrebbe richiedere molto tempo
prima che termini; l'utente deve contattare un amministratore per ricevere assistenza.

In modalità TOTP, tentare di determinare il livello di sincronizzazione con l'orologio di sistema
l'orologio del token e visualizzare il risultato. Queste informazioni possono essere utilizzate per aggiornare il
record di token dell'utente per compensare orologi scarsamente sincronizzati o per regolare
parametri di validazione. La chiave del token e il nome dell'algoritmo digest sono
ottenuto per il record token di appartenenza nome utente, se è dato; altrimenti la chiave
viene richiesto e l'algoritmo digest da utilizzare viene ottenuto dal comando
linea o il valore predefinito. Solo la prima password inserita elenco-password si usa. Il
-totp-timestep, -cifree -totp-base le opzioni sono efficaci durante questa operazione.

-Test
Esegui alcuni test automatici, quindi esci. Uno stato di uscita diverso da zero indica che si è verificato un errore.

-totp-mostra num
Visualizza una sequenza di password TOTP utilizzando i parametri attualmente in vigore:
dimensione dell'intervallo (-totp-timestep), numero di cifre (-cifre) e base (-base). Il
i parametri memorizzati dell'account non vengono modificati. Questo è principalmente destinato al debug
scopi.

Se un nome utente viene fornito (deve essere associato ad un dispositivo TOTP), la chiave e
vengono utilizzati altri parametri memorizzati dall'account a meno che non vengano sovrascritti dalla riga di comando
bandiere. La sequenza di password per num intervalli prima e dopo l'ora corrente,
vengono stampati insieme alla password per l'ora corrente.

Se no nome utente viene fornito, il programma richiede la chiave (che viene riprodotta) e utilizza
flag della riga di comando o valori predefiniti per i parametri. Quindi emette la password TOTP
per l'ora corrente ogni volta che si preme Invio/Invio. Digitando EOF la causa è immediata
terminazione.

-convalidare valore-otp
If valore-otp è la prossima password monouso prevista, a cui restituisce uno stato di uscita pari a zero
indicare il successo; qualsiasi altro valore indica un errore. Se nome utente viene fornito, parametri
per la convalida, inclusa la chiave, vengono ottenuti da tale account a meno che non vengano sovrascritti
la riga di comando. Lo stato del server non viene modificato; ad esempio, un contatore HOTP non lo è
Avanzate. Se no nome utente è dato, il -modalità deve essere utilizzato flag e i parametri
necessario per quella modalità, inclusa una chiave. Per la modalità HOTP, un valore del contatore
deve essere fornito. Per la modalità TOTP, i parametri della riga di comando sono efficaci durante questa operazione
convalida. dacstoken testerà se valore-otp convalida rispetto ai parametri in
effetto.

Le seguenti modificatore le bandiere sono intese:

-tutti
Con -impostato e no nome utente, applicare le modifiche a contro tutti i conti. Questo può essere usato
abilitare o disabilitare tutti gli account, ad esempio. IL -inkeys ed -outkey le bandiere sono
onorato. Se si verifica un errore l'elaborazione si interrompe immediatamente, nel qual caso solo alcuni
gli account potrebbero essere stati modificati.

-base num
Usa il num come base (radice) quando si visualizza un OTP. Il valore di num è limitato a
10 (il predefinito), 16, o 32.

-contatore num
Questo è il valore del contatore HOTP a 8 byte da impostare, espresso come valore esadecimale se preceduto da
per "0x" (o "0X"), altrimenti decimale. Gli zeri iniziali possono essere eliminati. Ciò implica HOTP
modalità. Per i dispositivi token non dovrebbe essere possibile reimpostare un contatore (contatore modulo
overflow) perché ciò comporterà la ripetizione della sequenza della password, presupponendo
che la chiave non sia cambiata; le implementazioni software potrebbero non avere questa restrizione,
tuttavia, fai attenzione alle implicazioni sulla sicurezza.

-cifre num
Usa il num cifre durante la visualizzazione di una OTP. Il valore di num è limitato a 6, 7, 8 (la
predefinito) o 9 con base 10. È limitato a 6 con base 32 e viene ignorato con
base 16 (output esadecimale).

-disattivare
Disattiva l'account per nome utente. local_token_authenticate modulo, e -aut ed
-convalidare flag, non consentirà all'utente di autenticarsi finché l'account non sarà stato
abilitato, anche se è ancora possibile eseguire altre operazioni sull'account. Se -abilitare
viene successivamente utilizzato, l'account diventerà utilizzabile per l'autenticazione ed è
ripristinato allo stato in cui era stato disattivato. Non è un errore disabilitare un
account già disabilitato.

-abilitare
Abilita l'account per nome utente. local_token_authenticate il modulo consentirà il
utente da autenticare. Non è un errore abilitare un account già abilitato.

-finestra hotp num
Se la password HOTP prevista non corrisponde alla password fornita, provare a corrispondere a
num password dopo la password prevista nella sequenza. Un valore pari a zero per num
disabilita questa ricerca.

-inkeys tipo di elemento
Per decrittografare le chiavi segrete, utilizzare il negozio identificato da tipo di elemento, presumibilmente
configurato in dacs.conf.

-chiave keyval
Usa il keyval come chiave segreta, espressa come stringa di cifre esadecimali.

Sicurezza
Fornire una chiave sulla riga di comando non è sicuro perché potrebbe essere visibile a
altri processi.

-file-chiave Nome del file
Leggere la chiave segreta, espressa come stringa di cifre esadecimali, da Nome del file. Se Nome del file is
"-", la chiave viene letta da stdin.

-richiesta chiave
Richiedi la chiave segreta, espressa come stringa di cifre esadecimali. L'input non viene riprodotto.

-modalità modalità otp
Specifica (senza distinzione tra maiuscole e minuscole) il tipo di token (la modalità del dispositivo OTP) da utilizzare
con -impostato, -crearee operazioni di convalida e sincronizzazione. IL modalità otp può essere
counter o hotp per la modalità contatore oppure time o totp per la modalità basata sul tempo. Questo
il contrassegno è obbligatorio quando si crea un nuovo account.

-outkey tipo di elemento
Per crittografare le chiavi segrete, utilizzare l'archivio identificato da tipo di elemento, presumibilmente definito
nel file dacs.conf.

-Pin pinval
Usa il pinval come PIN segreto per l'account.

Sicurezza
Fornire un PIN sulla riga di comando non è sicuro perché potrebbe essere visibile a
altri processi.

-vincoli dei pin str
Invece di usare PASSWORD_VINCOLI[14], utilizzare str (avente la stessa sintassi e
semantica) per descrivere i requisiti per un PIN.

Note:
I requisiti per un PIN si applicano ai PIN ottenuti tramite un flag della riga di comando e a quelli
ottenuto tramite importazione (utilizzando l'attributo "p"). I requisiti no
"retroattivo", tuttavia, quindi la modifica dei requisiti non influisce sui PIN di
account esistenti o importazione di account precedentemente esportati (con a
attributo "ph").

-file-pin Nome del file
Leggi il PIN segreto da Nome del file. Se Nome del file è "-", il PIN viene letto da stdin.

-richiesta pin
Richiedi il PIN segreto. L'input non viene riprodotto.

-rnd
Riservato per uso futuro.

semi str
Riservato per uso futuro.

-seriale str
Il numero di serie, str, è un identificatore (presumibilmente) univoco assegnato al token.
Questa opzione viene utilizzata con il -impostato, -crearee -elenco bandiere. Un numero di serie
identifica uno specifico dispositivo OTP e non è necessario mantenerlo segreto. La proprietà di unicità
viene applicato all'interno di un'unità di stoccaggio del tipo di articolo; ovvero i numeri di serie di tutti gli HOTP
i dispositivi devono essere univoci, i numeri di serie di tutti i dispositivi TOTP devono essere univoci e se
account per i due tipi di dispositivo vengono combinati, tutti i numeri di serie del dispositivo devono essere
unico. È accettata qualsiasi stringa stampabile. Se un client software sta generando
password, è possibile utilizzare il numero di serie del dispositivo o sceglierne uno adeguatamente descrittivo
stringa non già assegnata a un dispositivo.

Note:
Una giurisdizione che consente (o può eventualmente consentire) sia token hardware che
Le applicazioni client che generano software dovrebbero prendere in considerazione l'adozione di un modello formalizzato
schema di denominazione per i suoi token. Ad esempio, l'amministratore potrebbe aggiungere "-hw" a
il numero di serie del venditore per formare il dacstoken numero di serie. Per il software
token, l'amministratore potrebbe creare un file dacstoken numero di serie aggiungendo
"-sw" al numero di serie del fornitore del dispositivo.

-totp-delta num
Regola l'ora di base di num intervalli (ciascuno del numero di secondi della dimensione del passo) quando
calcolo di un TOTP. IL num può essere negativo, zero o positivo. Questo serve per correggere
per orologi non adeguatamente sincronizzati.

-totp-deriva nwindows
Per TOTP, utilizzare una dimensione della finestra di nwindows (in termini di dimensione dell'intervallo) per
convalida. Se nwindows is 0, il valore TOTP calcolato deve corrispondere a quello indicato
esattamente. Se nwindows is 1, Per esempio, dacstoken proverà a far corrispondere il TOTP indicato
valore negli intervalli precedente, corrente e successivo. Ciò consente agli orologi in
sistema in funzione dacstoken (o local_token_authenticate) e dispositivo di produzione di token
essere meno ben sincronizzati.

Sicurezza
Anche se compensa gli orologi scarsamente sincronizzati, aumentandone il valore
nwindows indebolisce il sistema estendendo la durata di una password monouso.

-totp-hash alg
Usa il alg come algoritmo digest con TOTP. Il valore di alg è limitato a (caso
in modo insensibile) SHA1 (predefinito), SHA256 o SHA512.

-totp-timestep secs
Usa il secs come dimensione dell'intervallo quando si calcola un TOTP. Deve essere maggiore di zero. IL
l'impostazione predefinita è 30 secondi.

Sicurezza
Anche se compensa gli orologi scarsamente sincronizzati, aumentandone il valore
secs indebolisce il sistema estendendo la durata di una password monouso.

-vfs vfs_uri
Usa il vfs_uri per ignorare il VFS[33] direttiva di configurazione in vigore. Questo può essere
utilizzato per configurare o riconfigurare auth_token, auth_hotp_token o auth_totp_token su
specificare il metodo di archiviazione per gli account su cui si interviene.

A parte i messaggi di errore, che vengono stampati nell'errore standard, tutto l'output va al file
uscita standard.

Di solito, a opzione dac sarà specificato per selezionare la giurisdizione per conto della quale
i conti vengono gestiti.

ESEMPI

Questi esempi presuppongono che il nome della giurisdizione da utilizzare sia EXAMPLE e la sua federazione
il dominio è esempio.com.

Per utilizzare questo metodo di autenticazione, a DACS l'amministratore potrebbe eseguire i seguenti passaggi
per ciascun dispositivo OTP assegnato a un utente:

1. Ottieni un token supportato, esamina come viene utilizzato per l'autenticazione e seleziona i valori
per i vari parametri. Ottenere la chiave segreta del dispositivo dal venditore; per
un dispositivo programmabile, selezionare una chiave casuale adatta e programmarla nel dispositivo.
I valori dei contatori correnti potrebbero anche essere ottenuti dal fornitore, sebbene lo sia
probabilmente inizializzato a zero; per un dispositivo programmabile, impostare il valore del contatore su
zero. Decidere se sarà richiesto un PIN (vedi TOKEN_REQUIRES_PIN[9]). Se un software
client viene utilizzato, installare il software sul dispositivo dell'utente (o chiedere all'utente di eseguire
così) e configurare il software.

2. Decidere dove verranno archiviate le informazioni sull'account e, se necessario, aggiungere un file adatto
VFS[33] direttiva su dacs.conf. L'impostazione predefinita (trovata in site.conf) mantiene l'account
informazioni in un file denominato auth_tokens all'interno del private predefinito di ciascuna giurisdizione
la zona:

VFS "[auth_token]dacs-kwv-fs:${Conf::FEDERATION_ROOT}/\
${Conf::FEDERATION_DOMAIN}/${Conf::JURISDICTION_NAME}/auth_tokens"

3. Generare chiavi per crittografare le informazioni sull'account (vedi Tokens ed segreto Tasti[34]) e
decidere dove verranno archiviati; ad esempio (ID utente, ID gruppo, percorso,
nome della giurisdizione e dominio della federazione possono variare):

% cd /usr/local/dacs/federations_root/example.com/EXAMPLE
% dacskey -uj ESEMPIO -q chiavi_token_auth
% chgrp www auth_token_keys
% chmod 0640 auth_token_keys

Se necessario, aggiungere un adatto VFS[33] direttiva su dacs.conf; l'impostazione predefinita, ovvero
utilizzato sopra, mantiene le informazioni sull'account in un file denominato auth_token_keys all'interno
l'area privata predefinita di ciascuna giurisdizione:

VFS "[auth_token_keys]dacs-fs:${Conf::FEDERATION_ROOT}/\
${Conf::FEDERATION_DOMAIN}/${Conf::JURISDICTION_NAME}/auth_token_keys"

4. Se è necessario che gli utenti accedano tramite dacs_autenticate(8)[2], è necessario configurare a
clausola Auth adatta in dacs.conf, ad esempio:


URL "token"
STILE "passato"
CONTROLLO "sufficiente"


5. Esistono diversi modi in cui un amministratore può procedere, a seconda di quanto
lo sforzo può essere svolto dagli utenti (ad esempio, se sono affidabili, i loro dati tecnici
capacità), quanti utenti ci sono (pochi o migliaia) e il livello di sicurezza
richiesto.

1. preparare un file contenente un XML record[35] per ciascun conto da creare; Se
Per utilizzare i PIN, assegnare un PIN casuale a ciascun account;

2. utilizzare il -importare[36] flag per creare gli account;

3. fornire all'utente il dispositivo token, il nome utente e (se necessario) il PIN iniziale
(magari verificando l'identità), fornendo ogni necessaria dimostrazione e
Istruzioni;

4. chiedere all'utente di impostare o reimpostare il PIN per l'account e chiedere all'utente di accedere
utilizzando il token per confermare il corretto funzionamento.

Per creare un account disabilitato per l'utente bobo per un dispositivo HOTP:

% dacstoken -uj ESEMPIO -mode hotp -serial 37000752 -key-file bobo.key -crea bobo

Dal file viene letta la chiave segreta dell'account (che non deve già esistere).
bobo.key. I nuovi account sono disabilitati per impostazione predefinita; utilizzo -abilitare per creare un account abilitato.

Una volta creato un account, è possibile sincronizzarlo con il token. Per sincronizzare
il token HOTP per l'utente bobo:

% dacstoken -uj ESEMPIO -sync 433268,894121,615120 bobo

In questo esempio, il token particolare ha prodotto le tre password consecutive 433268,
894121 e 615120. Si noti che la stringa di sequenza della password che segue il file -sincronizza la bandiera è
un singolo argomento che non può contenere spazi incorporati. Se la chiave per questo token è
19c0a3519a89b4a8034c5b9306db, la prossima password generata da questo token dovrebbe essere 544323
(con controvalore 13). Questo può essere verificato utilizzando -hotp-show:

% dacstoken -hotp-show 5 -contatore 10 -tasto 19c0a3519a89b4a8034c5b9306db
000000000000000a: 433268
000000000000000b:894121
000000000000000c:615120
000000000000000d: 544323
000000000000000e: 002442

Per abilitare l'account per l'utente bobo:

% dacstoken -uj ESEMPIO -enable -set bobo

Per impostare il PIN e abilitare l'account per l'utente bobo:

% dacstoken -uj ESEMPIO -enable -pin "CzAy" -set bobo

Per elencare tutti gli account in dettaglio:

% dacstoken -uj ESEMPIO -long

I -elenco flag è ridondante perché è l'operazione predefinita. IL -modalità, -contatore, ecc.
i modificatori non hanno effetto durante l'inserimento nell'elenco.

Per elencare solo l'account per bobo:

% dacstoken -uj ESEMPIO -list bobo

Lo stato di uscita sarà diverso da zero se l'utente non dispone di un account.

Per visualizzare l'account del dispositivo con numero di serie 37000752:

% dacstoken -uj ESEMPIO -serial 37000752

Il numero di serie, che dovrebbe identificare un token in modo univoco, è spesso stampato sul token
o può essere visualizzato dal token.

Per impostare il valore del contatore per l'account esistente di bobo:

% dacstoken -uj ESEMPIO -counter 9 -set bobo

Questa operazione potrebbe essere utilizzata per il test o con un token software. IL -sincronizza l'operazione è
più appropriato per un token hardware.

Per modificare il PIN del nome utente bobo:

% dacstoken -uj ESEMPIO -pin-prompt -set bobo

Il programma richiederà il nuovo PIN.

Per utilizzare un file di account alternativo, /secure/auth_tokens:

% dacstoken -uj ESEMPIO -vfs "dacs-kwv-fs:/secure/auth_tokens" -list

Per utilizzare nuove chiavi (facendo le stesse ipotesi di prima), aggiungere una direttiva VFS adatta a
dacs.conf; l'impostazione predefinita definisce il tipo di elemento auth_token_keys_prev come segue:

VFS "[auth_token_keys_prev]dacs-fs:${Conf::FEDERATION_ROOT}/\
${Conf::FEDERATION_DOMAIN}/${Conf::JURISDICTION_NAME}/auth_token_keys.prev"

% cd /usr/local/dacs/federations_root/example.com/EXAMPLE
% mv auth_token_keys auth_token_keys.prev
% dacskey -uj ESEMPIO -q chiavi_token_auth
% chgrp www auth_token_keys
% chmod 0640 auth_token_keys
% dacstoken -uj ESEMPIO -inkeys auth_token_keys.prev -set

DIAGNOSTICA

Il programma esce da 0 o da 1 se si è verificato un errore.

Utilizza dacstoken online utilizzando i servizi onworks.net