213 lines
5.4 KiB
Markdown
213 lines
5.4 KiB
Markdown
|
+++
|
||
|
|
title = "Introduzione a pass"
|
||
|
|
outputs = ["Reveal"]
|
||
|
|
|
||
|
|
+++
|
||
|
|
|
||
|
|
# Il problema della condivisione dei segreti
|
||
|
|
|
||
|
|
* i segreti condivisi sono ancora segreti ?
|
||
|
|
|
||
|
|
* attenzione a con chi si condivide, la fiducia nelle pratiche altrui.
|
||
|
|
|
||
|
|
* 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
|
||
|
|
|
||
|
|
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:
|
||
|
|
|
||
|
|
crittografia simmetrica: 1 password uguale per 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
|
||
|
|
|
||
|
|
richiede che tutti usino un software che supporti questa funzione (es. gnupg)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# il modo in cui condividere i segreti
|
||
|
|
|
||
|
|
* mail - il piu' semplice ma non automatizzato
|
||
|
|
|
||
|
|
* cloud - puo' essere manuale o automatizzato ma non c'e' versioning
|
||
|
|
|
||
|
|
* git - puo' essere automatizzato e ha il versioning
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# PASS
|
||
|
|
|
||
|
|
https://www.passwordstore.org/
|
||
|
|
|
||
|
|
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
|
||
|
|
|
||
|
|
* e' possibile specificare piu' di una chiave per cui crittare le password
|
||
|
|
|
||
|
|
* le password possono essere divise per progetto, ogni progetto con i suoi membri.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# Inizializzazione dello store
|
||
|
|
|
||
|
|
pass init KEY-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)
|
||
|
|
|
||
|
|
in genere meglio usare il key-id per essere certi di usare proprio la chiave che vogliamo,
|
||
|
|
e non semplicemente la chiave associata a un indirizzo email (che chiunque potrebbe creare).
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# Aggiunta di una password
|
||
|
|
|
||
|
|
pass generate unit/wiki 32
|
||
|
|
|
||
|
|
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
|
||
|
|
|
||
|
|
pass insert unit/ldap-root
|
||
|
|
|
||
|
|
aggiunge una password che deve essere digitata (2 volte per conferma)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# Visualizzazione di una password
|
||
|
|
|
||
|
|
pass ls
|
||
|
|
|
||
|
|
vi mostra tutto l'albero delle password salvate
|
||
|
|
|
||
|
|
pass show unit/wiki
|
||
|
|
|
||
|
|
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).
|
||
|
|
Per non mostrarla a video ma copiarla nella clipboard aggiungere l'opzione "-c"
|
||
|
|
|
||
|
|
(bash completion ???)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# modifica ed eliminazione di una password
|
||
|
|
|
||
|
|
pass edit unit/wiki
|
||
|
|
|
||
|
|
modificare una password esistente
|
||
|
|
|
||
|
|
pass rm unit/wiki
|
||
|
|
|
||
|
|
eliminare una password
|
||
|
|
|
||
|
|
pass mv unit/nextcloud unit/web_team/nextcloud
|
||
|
|
|
||
|
|
sposta una password in un'altra posizione
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# organizzare le password in cartelle/progetti
|
||
|
|
|
||
|
|
le password possono salvate come un albero di cartelle e files
|
||
|
|
|
||
|
|
pass generate personal/posta_ai
|
||
|
|
|
||
|
|
ora potete vedere le password divise per le varie cartelle/directory,
|
||
|
|
in pratica ogni directory puo' essere un progetto
|
||
|
|
ogni directory/progetto puo' avere il suo .gpg-id che contiene le chiavi per cui crittare le pwd in quel progetto
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# 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 firmarla
|
||
|
|
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)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# la distribuzione
|
||
|
|
|
||
|
|
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)
|
||
|
|
* qtpass (GUI per linux)
|
||
|
|
* passff (firefox extension)
|
||
|
|
* browserpass (chrome extension)
|
||
|
|
* password-store.el (emacs package)
|
||
|
|
* 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
|
||
|
|
le pwd salvate in pass ????
|
||
|
|
|
||
|
|
https://docs.ansible.com/ansible/latest/plugins/lookup/passwordstore.html
|
||
|
|
|
||
|
|
|
||
|
|
# accortezze
|
||
|
|
|
||
|
|
* 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.
|
||
|
|
|
||
|
|
* non si deve usare su server remoti (perche' non e' una buona idea usare GPG su macchine remote).
|