first revision
This commit is contained in:
parent
750dff73f3
commit
c1c89408f9
|
@ -4,58 +4,58 @@ outputs = ["Reveal"]
|
||||||
|
|
||||||
+++
|
+++
|
||||||
|
|
||||||
# Il problema della condivisione dei segreti
|
## Il problema della condivisione dei segreti
|
||||||
|
|
||||||
* i segreti condivisi sono ancora segreti ?
|
* i segreti "informatici" possono essere piu' inviolabili di un caveau, vantaggi e svantaggi.
|
||||||
|
|
||||||
|
* condividere i segreti alleggerisce la centralita' dell'individuo per la loro recuperabilita',
|
||||||
|
il rovescio della medaglia e' che la superficie di attacco aumenta.
|
||||||
|
|
||||||
* attenzione a con chi si condivide, la fiducia nelle pratiche altrui.
|
* attenzione a con chi si condivide, la fiducia nelle pratiche altrui.
|
||||||
|
|
||||||
* quando e' necessario condividere un segreto ?
|
* quando e' necessario condividere un segreto ?
|
||||||
|
|
||||||
quando si lavora in gruppo, e tutto il gruppo deve avere accesso alle cose segrete del gruppo.
|
---
|
||||||
|
|
||||||
|
### problematiche nella condivisione dei segreti
|
||||||
|
|
||||||
|
* i segreti devono essere custoditi e trasmessi crittati
|
||||||
|
|
||||||
|
* i segreti devono essere disponibili per il gruppo in modo immediato (no telefonate in urgenza)
|
||||||
|
|
||||||
|
* gli aggiornamenti devono essere il piu' possibile automatizzati
|
||||||
|
|
||||||
|
* deve essere semplice revocare l'accesso ai segreti
|
||||||
|
|
||||||
|
* deve essere semplice aggiungere una persona all'accesso dei segreti.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# problematiche nella condivisione dei segreti
|
#### il "formato" in cui salvare i segreti
|
||||||
|
|
||||||
i segreti devono essere custoditi e trasmessi crittati
|
|
||||||
|
|
||||||
se si vuole celarne ulteriormente l'esistenza anche il canale di comunicazione deve essere crittato
|
|
||||||
|
|
||||||
i segreti devono essere disponibili per il gruppo in modo immediato (no telefonate in urgenza)
|
|
||||||
|
|
||||||
i segreti (e gli eventuali loro aggiornamenti) devono essere resi disponibili in modo il piu'
|
|
||||||
possibile semplice ed automatizzato.
|
|
||||||
|
|
||||||
deve essere semplice revocare l'accesso ai segreti a una persona
|
|
||||||
|
|
||||||
deve essere semplice aggiungere una persona all'accesso dei segreti.
|
|
||||||
|
|
||||||
deve essere possibile tornare a una versione precedente in caso di problemi.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# il formato in cui salvare i segreti
|
|
||||||
|
|
||||||
ovviamente devono essere crittati in qualche modo:
|
ovviamente devono essere crittati in qualche modo:
|
||||||
|
|
||||||
crittografia simmetrica: 1 password uguale per tutti.
|
* crittografia simmetrica: una password uguale per tutti.
|
||||||
|
|
||||||
e' piu' semplice da implementare, ma c'e' il problema di comunicare la password a tutti
|
e' piu' semplice da implementare, ma c'e' il problema di comunicare la password a tutti
|
||||||
|
|
||||||
crittografia asimmetrica: ognuno ha le sue credenziali per decrittare
|
* crittografia asimmetrica: ognuno ha le sue credenziali per decrittare
|
||||||
|
|
||||||
richiede che tutti usino un software che supporti questa funzione (es. gnupg)
|
richiede che tutti usino un software che supporti questa funzione (es. gnupg)
|
||||||
|
|
||||||
|
* un file unico con tutto (es. keepassxc) o un file per segreto
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# il modo in cui condividere i segreti
|
### il modo in cui condividere i segreti
|
||||||
|
|
||||||
* mail - il piu' semplice ma non automatizzato
|
ce ne sono a bizzeffe, es.
|
||||||
|
|
||||||
* cloud - puo' essere manuale o automatizzato ma non c'e' versioning
|
* mail - il piu' semplice ma non automatizzato
|
||||||
|
|
||||||
* git - puo' essere automatizzato e ha il versioning
|
* cloud - puo' essere manuale o automatizzato ma non e' detto che ci sia il versioning
|
||||||
|
|
||||||
|
* git - puo' essere automatizzato e ha il versioning, e pass ne automatizza l'uso
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
@ -63,15 +63,7 @@ outputs = ["Reveal"]
|
||||||
|
|
||||||
https://www.passwordstore.org/
|
https://www.passwordstore.org/
|
||||||
|
|
||||||
apt-get install pass
|
$ sudo apt-get install pass
|
||||||
|
|
||||||
dipendenze:
|
|
||||||
|
|
||||||
* gnupg per la crittazione
|
|
||||||
|
|
||||||
* git per la distribuzione (non obbligatorio)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
* permette di salvare ogni singola password in un file crittato con gpg
|
* permette di salvare ogni singola password in un file crittato con gpg
|
||||||
|
|
||||||
|
@ -81,9 +73,17 @@ dipendenze:
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Inizializzazione dello store
|
### Inizializzazione dello store
|
||||||
|
|
||||||
pass init KEY-ID
|
$ gpg --keyid-format long --list-keys putro@autistici.org
|
||||||
|
|
||||||
|
pub rsa4096/EA0C9FEE5FAC40A1 2018-04-22 [SC] [expires: 2028-04-19]
|
||||||
|
6CD5DB9995A2519D38A635E6EA0C9FEE5FAC40A1
|
||||||
|
uid [ultimate] putro <putro@autistici.org>
|
||||||
|
sub rsa4096/FAD54D2D6C585FCE 2018-04-22 [E] [expires: 2028-04-19]
|
||||||
|
|
||||||
|
|
||||||
|
$ pass init KEY-ID
|
||||||
|
|
||||||
questo crea la cartella $HOME/.password-store/ contenente il file .gpg-id
|
questo crea la cartella $HOME/.password-store/ contenente il file .gpg-id
|
||||||
che contiene il KEY-ID (che puo' essere sia il key id della chiave che un indirizzo email)
|
che contiene il KEY-ID (che puo' essere sia il key id della chiave che un indirizzo email)
|
||||||
|
@ -93,56 +93,56 @@ e non semplicemente la chiave associata a un indirizzo email (che chiunque potre
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Aggiunta di una password
|
### Aggiunta di una password
|
||||||
|
|
||||||
pass generate unit/wiki 32
|
$ pass generate unit/wiki 32
|
||||||
|
|
||||||
genera (automaticamente) una password di 32 caratteri casuali e la salva crittata per la chiave
|
genera (automaticamente) una password di 32 caratteri casuali e la salva crittata per la chiave
|
||||||
definita in $HOME/.password-store/.key-id nel file $HOME/.password-store/unit/wiki.gpg
|
definita in $HOME/.password-store/.key-id nel file $HOME/.password-store/unit/wiki.gpg
|
||||||
|
|
||||||
pass insert unit/ldap-root
|
$ pass insert unit/ldap-root
|
||||||
|
|
||||||
aggiunge una password che deve essere digitata (2 volte per conferma)
|
aggiunge una password che deve essere digitata (2 volte per conferma)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Visualizzazione di una password
|
### Visualizzazione di una password
|
||||||
|
|
||||||
pass ls
|
$ pass ls (o anche solo pass)
|
||||||
|
|
||||||
vi mostra tutto l'albero delle password salvate
|
vi mostra tutto l'albero delle password salvate
|
||||||
|
|
||||||
pass show unit/wiki
|
$ pass show unit/wiki
|
||||||
|
|
||||||
vi mostra la password (a schermo) dopo averla decrittata (puo' essere necessario digitare la
|
vi mostra la password (a schermo) dopo averla decrittata (puo' essere necessario digitare la
|
||||||
password della chiave gpg se il gpg-agent non l'ha in memoria).
|
password della chiave gpg se il gpg-agent non l'ha in memoria).
|
||||||
Per non mostrarla a video ma copiarla nella clipboard aggiungere l'opzione "-c"
|
Per non mostrarla a video ma copiarla nella clipboard aggiungere l'opzione "-c"
|
||||||
|
|
||||||
(bash completion ???)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# modifica ed eliminazione di una password
|
### modifica ed eliminazione di una password
|
||||||
|
|
||||||
pass edit unit/wiki
|
|
||||||
|
|
||||||
modificare una password esistente
|
modificare una password esistente
|
||||||
|
|
||||||
pass rm unit/wiki
|
$ pass edit unit/wiki
|
||||||
|
|
||||||
eliminare una password
|
eliminare una password
|
||||||
|
|
||||||
pass mv unit/nextcloud unit/web_team/nextcloud
|
$ pass rm unit/wiki
|
||||||
|
|
||||||
sposta una password in un'altra posizione
|
spostare o rinominare una password
|
||||||
|
|
||||||
|
$ pass mv unit/ldap-root unit/slapd/root
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# organizzare le password in cartelle/progetti
|
### organizzare le password in cartelle/progetti
|
||||||
|
|
||||||
le password possono salvate come un albero di cartelle e files
|
le password possono salvate come un albero di cartelle e files
|
||||||
|
|
||||||
pass generate personal/posta_ai
|
$ pass insert personal/bancaetica/pin
|
||||||
|
|
||||||
|
$ pass insert personal/autistici.org/mail
|
||||||
|
|
||||||
ora potete vedere le password divise per le varie cartelle/directory,
|
ora potete vedere le password divise per le varie cartelle/directory,
|
||||||
in pratica ogni directory puo' essere un progetto
|
in pratica ogni directory puo' essere un progetto
|
||||||
|
@ -150,63 +150,104 @@ ogni directory/progetto puo' avere il suo .gpg-id che contiene le chiavi per cui
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# aggiungere chiavi di crittazione
|
### il multiline
|
||||||
|
|
||||||
se ad es. Terry entra nel progetto unit, bisogna aggiungere il suo key-id al file .gpg-id del progetto,
|
con l'opzione -m pass vi permette di inserire piu' dati in un file, non solo la password
|
||||||
in ~/.password-store/unit/.gpg-id
|
ma ad esempio che lo username (utile per i form di login nei siti)
|
||||||
|
|
||||||
NOTA IMPORTANTE: la sua chiave deve essere "trusted", quindi dovete importarla anche nel vostro keyring personale e firmarla
|
Yw|ZSNH!}z"6{ym9pI
|
||||||
gpg --edit-key jane@acme.org
|
URL: *.pippo.com/*
|
||||||
gpg> lsign
|
Username: Chicken@example.com
|
||||||
|
Secret Question 1: What is your childhood best friend's superhero fantasy?
|
||||||
e poi il progetto va reinizializzato in modo che tutte le pwd al suo interno siano recrittate
|
Phone Support PIN #: 84719
|
||||||
usando i key-id aggiornati.
|
|
||||||
|
|
||||||
pass init -p unit/ $(cat ~/.password-store/unit/.gpg-id)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# la distribuzione
|
## pass clients
|
||||||
|
|
||||||
bisogna prendere tutta la cartella del progetto e passarla in qualche modo a chi di dovere
|
|
||||||
|
|
||||||
si puo' fare in molti modi, ma forse il piu' comodo e' git perche' consente il versioning.
|
|
||||||
|
|
||||||
inoltre e' possibile creare un repository git per i vari progetti, sincronizzando quindi i dati dei
|
|
||||||
diversi progetti in modo compartimentato.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# estensioni
|
|
||||||
|
|
||||||
* pass-tomb
|
|
||||||
* pass-otp
|
|
||||||
* pass-import
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# pass clients
|
|
||||||
|
|
||||||
* passmenu (dmenu script)
|
* passmenu (dmenu script)
|
||||||
|
* rofi-pass (https://www.youtube.com/watch?v=VlHBRYTtm3s)
|
||||||
|
* https://gitlab.com/repomaa/autopass.cr
|
||||||
* qtpass (GUI per linux)
|
* qtpass (GUI per linux)
|
||||||
* passff (firefox extension)
|
* passff (firefox extension, richiede passff-host)
|
||||||
* browserpass (chrome extension)
|
* browserpass (chrome extension)
|
||||||
* password-store.el (emacs package)
|
* password-store.el (emacs package)
|
||||||
* pass-git-helper (git credentials helper)
|
* pass-git-helper (git credentials helper)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# ansible e pass
|
|
||||||
|
|
||||||
esiste un modulo ansible per usare pass che potrebbe consentire di non usare il vault ma direttamente
|
### la distribuzione dei segreti
|
||||||
le pwd salvate in pass ????
|
|
||||||
|
|
||||||
https://docs.ansible.com/ansible/latest/plugins/lookup/passwordstore.html
|
bisogna prendere tutta la cartella del progetto e passarla in qualche modo a chi di dovere
|
||||||
|
|
||||||
|
si puo' fare in molti modi, ma forse il piu' comodo e' git, anche perche' consente il versioning.
|
||||||
|
|
||||||
|
inoltre e' possibile creare un repository git per i vari progetti, sincronizzando quindi i dati dei
|
||||||
|
diversi progetti in modo compartimentato.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### impostare pass per il progetto "unit"
|
||||||
|
|
||||||
|
$ cd ~/.passwordstore
|
||||||
|
|
||||||
|
$ git clone ssh://git@git.abbiamoundominio.org:10022/unit/pass.git unit
|
||||||
|
|
||||||
|
in questo modo cloniamo il repository pass di unit, che contiene anche il .gpg-id con le chiavi per cui crittare.
|
||||||
|
|
||||||
|
ovviamente il repository e' bene che non sia pubblico (al momento e' privato ai membri di unit come definiti in gitea).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### l'automazione di git
|
||||||
|
|
||||||
|
ogni volta che modifichiamo qualcosa nel repository, pass crea automaticamente un commit
|
||||||
|
|
||||||
|
se si crea un file unit/.git/hooks/post-commit che contiene
|
||||||
|
|
||||||
|
git pull
|
||||||
|
git push
|
||||||
|
|
||||||
|
e lo si rende eseguibile, ad ogni modifica c'e' automaticamente il pull/push
|
||||||
|
|
||||||
|
P.S. nel gitignore e' specificato di ignorare qualsiasi file eccetto il .gpg-id e i files .gpg, per evitare
|
||||||
|
di committare cose che non si dovrebbero.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### aggiungere chiavi di crittazione
|
||||||
|
|
||||||
|
se ad es. Terry entra nel progetto unit, bisogna aggiungere il suo key-id al file .gpg-id del progetto,
|
||||||
|
in ~/.password-store/unit/.gpg-id
|
||||||
|
|
||||||
|
NOTA IMPORTANTE: la sua chiave deve essere "trusted", quindi dovete importarla anche nel vostro keyring personale e
|
||||||
|
impostare il trust a livello ultimate, oppure firmarla, ma SOLO SE AVETE VERIFICATO che la chiave sia davvero fidata.
|
||||||
|
|
||||||
|
$ gpg --edit-key jane@acme.org
|
||||||
|
$ gpg> lsign
|
||||||
|
|
||||||
|
e poi il progetto va reinizializzato in modo che tutte le pwd al suo interno siano recrittate usando i key-id aggiornati.
|
||||||
|
|
||||||
|
$ pass init -p unit/ $(cat ~/.password-store/unit/.gpg-id)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## estensioni
|
||||||
|
|
||||||
|
* https://github.com/tijn/awesome-password-store
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
# accortezze
|
# accortezze
|
||||||
|
|
||||||
* se qualcuno vede la cartella delle password, dai nomi dei file puo' capire a cosa serve la password
|
* se qualcuno vede la cartella delle password, dai nomi dei file puo' capire a cosa serve la password
|
||||||
che c'e' in quel file. Quindi magari il repository pur contenendo password crittate e' meglio che non sia pubblico.
|
che c'e' in quel file.
|
||||||
|
|
||||||
* non si deve usare su server remoti (perche' non e' una buona idea usare GPG su macchine remote).
|
* non si deve usare su server remoti (perche' non e' una buona idea usare GPG su macchine remote).
|
||||||
|
|
||||||
|
* il .gpg-id contiene le chiavi per cui crittare, VERIFICARE sempre che le chiavi siano quelle giuste
|
||||||
|
(quindi prima di dare un trust o di firmarle, essere certi dell'autenticita' della chiave)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user