Bref, j’ai acheté un keylogger

Avant d'en venir au dispositif qui donne son titre à cet article il me semble important de donner un peu de contexte. Je cherche depuis plusieurs mois maintenant à me procurer un bon et beau clavier mécanique. "Beau" est bien évidemment un critère totalement subjectif, et si "bon" inclue des éléments objectifs comme la solidité, la fiabilité, il intègre lui-aussi des éléments totalement subjectifs.
Ce qu'il y a de merveilleux dans le monde des claviers mécaniques haut de gamme, c'est qu'il est presque possible de faire n'importe quoi : si aucune marque ne propose un clavier tout fait qui vous corresponde, il est presque toujours possible d'en construire un qui répondent à nombre de vos critères. Presque, parce que la France n'est pas tout à fait cœur de cible : trop peu de demande pour susciter une offre variée, me suis-je laissé dire. Aussi le critère "AZERTY" ou ISO-FR est sans doute un des plus difficiles à remplir. Vous trouverez tous les claviers ou jeux de touches en ANSI-US, une portion raisonnable en ISO-UK, ISO-NO, ISO-DE, mais presque aucuns en ISO-FR. Ceux que vous trouverez seront les plus grand public, souvent des claviers de gamer dans des formats réduits comme le populaire TKL ("ten key less"), qui comme son nom l'indique fait l'impasse sur pas mal de touches.
Vortex ViBE © vortexgear.twAprès quelques mois d'étude du marché, de documentation sur les technologies, sur les capacités des claviers, sur les marques et leur réputation, de recherche d'un modèle qui réponde à mes besoins et à mes envies (surtout), j'ai fini par jeter mon dévolu sur deux modèles : le ViBE de Vortex Gear (photo ci-dessus), et le Tab 90M aussi chez Vortex Gear.
Bien sûr, je les veux en ISO-FR : je tape autant de texte que je code ou que je joue. J'ai besoin que mes accents et cédille soient accessibles sans contorsion. Et très honnêtement si je devais changer de disposition de touches j'irais sur un BEPO, pas sur l'archaïque ANSI-US.
J'ai plein d'autres critères que je ne détaille pas ici car ils n'ont aucun lien avec cette histoire de keylogger.
Comme on le remarque rapidement, le Vortex ViBE ne dispose pas de toutes les touches habituelles d'un clavier étendu : exit les flèches, page-down, page-up, etc. Toutes les touches entre le pavé numérique et le bloc de touches principal ont disparu. Par un jeu de combinaison de touches, il est possible d'utiliser le pavé numérique pour jouer le rôle des touches absentes. Dans mon quotidien, je fais un grand usage des flèches de navigation et du pavé numérique. En tout cas c'est ce qu'il me semble. J'utilise aussi les touches de fonctions (absentes sur le ViBE), et les touches "multimédia" du clavier étendu Apple qui est branché sur mes machines au travail et à la maison.
Je tenais donc à évaluer précisément l'usage que je fais de ces touches, histoire de ne pas prendre une trop grosse claque quand le fameux clavier arriverait. Et quoi de mieux pour savoir ce qu'on l'on tape toute la journée qu'un keylogger ? (réponse : rien).
La solution gratuite est assez facile à mettre en œuvre : trouver et installer sur mon poste un keylogger logiciel qui écrit dans un fichier texte tout ce qui passe par mon clavier. Mais cette solution est problématique à plusieurs égards. Notamment j'ai plusieurs machines. À la maison j'ai un OSX, un Windows et un FreeBSD, utilisés via un unique clavier physique au travers d'un switch USB. Il faudrait que je trouve une solution logicielle homogène à installer sur les trois systèmes. Au boulot et bien, juste non. Installer un keylogger logiciel qui pourrait exfiltrer à mon insu mes frappes clavier n'est réellement pas une bonne idée. Par ailleurs une solution logicielle attraperait aussi au vol ce qui sort de mes Yubikeys, et ça non plus ça ne me convient pas.
keygrapper © keelog.comLa solution matérielle qui stocke mes frappes clavier en son sein, sans rien faire sortir et qui s'affranchit totalement du système sur lequel est branché le clavier me semble donc la plus sûre à tout point de vue, et la plus adaptée à mes besoins. Bien évidement je me suis assuré que le dongle n'exfiltre aucune données via mes machines. L'exfiltration de données via un réseau hertzien est assez peu probable même si le dispositif semble assez grand pour héberger une SIM et l'électronique nécessaire pour tout renvoyer par SMS. Par ailleurs comme le dongle est branché sur un unique clavier, il m'est toujours possible de saisir des données sensibles via un autre clavier :)
Ceci posé, n'installez pas de keylogger chez vous sans savoir très exactement ce que vous faites et dans quoi vous mettez le doigt.

J'utilise le keylogger matériel depuis quelques dizaines de minutes, mais je vois déjà qu'il me faudra peut être tenter de le régler un peu finement : je tape trop vite pour lui, et pas mal de mots sont tronqués dans la capture. Cela a peut être aussi à voir avec le fait que c'est un modèle spécial supposé filtrer le trafic USB d'un clavier Apple. Les claviers Apple sont des hub USB, et sur le mien j'ai branché un casque/micro USB qui peut donc générer pas mal d'interférences au niveau du dongle qui connecte le clavier au switch USB. Quoi qu'il en soit ce n'est pas un drame puisque ce que je cherche à obtenir c'est une vue statistique de mes frappes, de mon utilisation du clavier.
Petit exemple de ce que cela donne :
[Sh]Parailleur comme le donge est branc sur un uniqu cver, il n[Bck]mest [Bck][Bck][Bck][Bck]e'est
Certains mots sont sévèrement amputés, mais l'esprit est là ! J'espère pouvoir obtenir des statistiques représentatives assez rapidement.

Bref, j'ai acheté un keylogger.

Related posts

Recherche Administratrice/teur Systèmes en alternance

Au sein du Service Opérations de la DSI de l'Université Lyon 2, nous cherchons un ou une Administrateur/trice Systèmes en alternance pour nous aider à relever des défis au quotidien.
Lieu de travail : campus de Bron (arrêt de tram T2 Europe Université).

  • Vous habitez la région Lyonnaise ;
  • Vous êtes motivée par les enjeux de la gestion d’un parc de plus de 400 serveurs Linux RedHat/CentOS (70%), Windows, FreeBSD ;
  • Les problématiques d’une ferme de virtualisation multi-site avec balance de charge, PRA, sauvegardes croisées ne vous font pas peur ;
  • Les infrastructures à fort enjeu de disponibilité, les outils d’automatisation, de monitoring et les SIEM vous intéressent ;
  • Vous êtes passionnée par les problématiques système et souhaitez évoluer dans un environnement riche et varié ;
  • Vous êtes curieuse, très rigoureuse et vous avez le sens du service.

Si vous vous reconnaissez dans ce profil, contactez-moi !

terminal - édition d'un script shell

Édition d'un script shell dans le terminal

Related posts

Install Fast Incident Response (FIR) on FreeBSD

FIR login screen FIR is a web application designed by CERT Société Générale. It's coded in Python and uses Django.

Installation as documented uses Nginx and pip, two tools I'm not using. I already run several Apache servers, and I do prefer relying on pkg for software installation. For me, pip is more a developer tool: very convenient with virtualenv but not what I would use for production.
If you want to use pip, just go with the official documentation :)

So on a FreeBSD 11.2-RELEASE server, you need to install all required packages. Be careful, py27-MySQLdb uses mysql56-server, not mysql57-server, and FIR works with Python 2.7, not 3.x (as far as I can say).

$ sudo pkg install gettext mysql56-server py27-pip py27-virtualenv git apache24 uwsgi py27-MySQLdb py27-django py27-cssselect py27-django-filter py27-djangorestframework py27-flup6 py27-gunicorn py27-lxml py27-markdown py27-pymongo py27-pyquery py27-dateutil py27-pytz py27-six py27-django-treebeard py27-markdown2 py27-bleach py27-python-gettext

Add those lines to /etc/rc.conf:

mysql_enable="yes"
uwsgi_enable="yes"
apache24_enable="yes"

The requirement list includes dj-database-url and whitenoise, but I was not able to find them in FreeBSD's packages. I've just ignored them and everything seems to work fine.
If needed, sudo pip install… should do the trick.

Follow the documentation:
- configure MySQL
- install FIR without virtualenv (in /usr/local/www for example)
- create and tune production.py
- create installed_apps.txt (you do want the plugins)
- create tables in the db
- create the admin user
- populate the db
- collect static files

On FreeBSD we run uwsgi as a service, under uwsgi UID. So chown must reflect that:

$ sudo chown uwsgi logs/errors.log uploads
$ sudo chmod 750 logs/errors.log uploads

Skip the uWSGI section of the documentation. Instead, create config file for uwsgi with this content:

$ cat /usr/local/etc/uwsgi/uwsgi.ini
[uwsgi]
chdir = /usr/local/www/FIR
module = fir.wsgi

You can now start the service:

$ sudo service uwsgi start

Then, skip the nginx part, and go configure Apache:

- load proxy_module and proxy_uwsgi_module in httpd.conf
- add the following to the relevant part of Apache configuration:

# FIR
ProxyPass /FIR unix:/tmp/uwsgi.sock|uwsgi://usr/local/www/FIR
Alias /files/ /usr/local/www/FIR/files/
Alias /static/ /usr/local/www/FIR/static/
<Directory /usr/local/www/FIR/static>
	Require all granted
</Directory>
<Directory /usr/local/www/FIR/files>
	Require all granted
</Directory>

Restart Apache: you're all set, point your browser to https://your-server/FIR/

Related posts

Écriture inclusive et risques de sécurité

Je ne vais pas rentrer dans le débat du pour ou contre l’écriture inclusive. Mon propos est ici d’étudier l’impact d’une forme de graphie utilisée dans le cadre de l’écriture inclusive française sur la sécurité des systèmes d’information.

Il existe différentes formes ou manière de faire de l’écriture inclusive, utilisant différents artifices typographiques. Malheureusement, une des formes les plus élémentaires - celle qui utilise le point de ponctuation pour séparer les blocs - crée parfois des noms de domaines, comme par exemple : enseignant.es, doctorant.es, etc.

L’auteur d’un texte rédigé avec cette forme d’écriture inclusive peut donc se trouver rapidement à truffer sa prose de noms de domaine espagnols. Dans le cas d’un support totalement maîtrisé comme le papier ou l’image, l’impact est faible car le texte n’est pas immédiatement accessible à la machine. Il faudrait opérer une reconnaissance optique de caractère pour retrouver un texte électronique exploitable.

Malheureusement pour cette forme d’écriture, les supports numériques prévalent de plus en plus, et la maîtrise du support disparaît presque totalement au profit d’intermédiaires, de médias, qui peuvent décider d’améliorer l’expérience utilisateur sans demander son avis à l’auteur initial. Que cet intermédiaire soit un logiciel bureautique, un CMS, une plateforme de réseau social, une application de SMS, une messagerie instantanée, etc. nombreux sont ceux qui vont s’arroger le droit d’activer les URL qu’ils détectent dans les contenus soumis. Ainsi, quand un auteur écrit que « les étudiant.es peuvent se porter candidat.es au concours d’infirmier.es », il est bien possible que le média de publication informe les lecteurs que « les étudiant.es peuvent se porter candidat.es au concours d’infirmier.es ». La différence est de taille : les mots suffixés en .es sont devenus des URL actives.

Qui dit URL actives dit aussi : téléchargement d’un aperçu, possibilité de clic volontaire ou non sur une de ces URL, et dans des cas rares de vulnérabilité logicielle, possibilité de téléchargement de l’URL sans clic de la part du lecteur.

À titre de démonstration et d'expérience j'ai personnellement enregistré les noms étudiant.es et enseignant.es, puis je les ai faits pointer sur une page web que je maîtrise pour mesurer le comportement des utilisateurs en présence de ces noms de domaines. Sur une période de 31 jours, je mesure 5265 requêtes GET tous visiteurs confondus (avec une majorité de robots donc). Sur la même période, je mesure environ 350 visiteurs réels, soit plus de 10 par jour en moyenne, et avec un pic à 54 visiteurs un jour particulier.

Nombre de "GET" par jour sur étudiant.es et enseignant.es

Nombre de "GET" par jour sur étudiant.es et enseignant.es


Estimation du nombre de "vrais visiteurs" par jour sur étudiant.es et enseignant.es


Les traces sur le serveur web montrent aussi qu'un grand nombre des requêtes de robots sont faites par des plateformes de réseau social, au moment où ces plateformes analysent le lien posté par l'utilisateur (création de l'aperçu, de l'URL raccourcie, détection de malware, analyse du contenu promu par l'utilisateur, etc.). Par exemple : Twitterbot, Facebookbot, EveryoneSocialBot, et autres.

L’URL ainsi activée va en général se retrouver sur des supports largement diffusés. On peut penser notamment à un CMS d’institution, mais aussi à des documents PDF, des emails, des messages diffusés sur des plateformes de réseau social comme Facebook, Twitter, Linked’In. Dans une grande université française, un seul auteur peut ainsi toucher directement 20000 à 60000 individus, et indirectement bien plus.

Il est donc normal dans un tel contexte d’envisager ce qu’il se passerait si par exemple quelqu’un décidait d’enregistrer tout ou partie de ces noms de domaines espagnols pour faire des choses avec :

  • Faire du profit (affichage de publicité, vente de contrefaçon, pornographie, etc.)
  • Attaquer les lecteurs de certains contenus en distribuant des malwares
  • Lancer une campagne de phishing contre les lecteurs de ces contenus
  • Porter atteinte à l’image de l’auteur (incitation à la haine, diffamation, etc.)

L’attaque en elle-même est extrêmement simple et économique. La location d’un nom de domaine à l’année coûte une poignée d’euros, et la plupart de ces mots français sont disponibles en .es. Par ailleurs, elle peut se produire à tout moment, et le plus tard est même le mieux : plus le nom de domaine est répandu, plus il est diffusé largement et dans un grand nombre de documents et supports, plus son exploitation devient intéressante.

Comme évoqué ci-dessus, les motivations de l’attaquant peuvent être diverses, néanmoins les effets de l’attaque sur l’auteur ou sur son entreprise/institution sont toujours les mêmes. Inévitablement il se produit un dégât d’image : personne ne trouverait normal en cliquant sur le mot canditat.es dans une communication officielle d’entreprise d’arriver sur un site pornographique (sauf bien évidemment si cette entreprise gère le site en question). Idem si le lecteur voit son antivirus passer au rouge suite à un clic sur infirmier.es.

Ensuite, il peut se produire une perte pour l’entreprise ou pour l’auteur : perte de temps et d’argent car il faut rapidement neutraliser les documents ou les URL dans les documents publiés. Cette opération curative est indispensable, mais impossible en pratique à faire en totalité : en effet il est impossible d’aller modifier les emails déjà envoyés, les documents PDF ou bureautique déjà téléchargés par le public, les SMS, etc.

Si l’attaquant a choisi une posture très offensive en faisant pointer les URL vers des malwares, alors l’auteur des contenus entre dans un nouveau cercle des Enfers : il pourra être amené à découvrir ce qu’il se produit lorsque Google décide de faire disparaître son site web des résultats de recherche, ce qu’il se produit quand tous les antispam de la planète décident de bloquer les emails qu’il envoie. Le blocage ne sera pas immédiat bien sûr, laissant à l’attaquant une fenêtre de tir pendant laquelle il pourra infecter d’innocents lecteurs. D’une pierre deux coups, en quelques sortes. Je n’ai pas de certitude sur le comportement des réseaux sociaux dans ce cas de figure, mais il est possible que certains décident de supprimer les messages contenant des liens vers des malwares, que d'autres suspendent le compte de l'auteur. Autant dire que tout à coup, les choses vont devenir très compliquées pour l’auteur.

À mon avis, il y a ici un risque qui vaut la peine d'être pris en compte. Même si on constate que le nombre de clics volontaires ou non sur ces liens automatiques est relativement faible, il reste très largement supérieur au "taux de conversion" habituel d'une campagne de phishing par email. Et nous protégeons tous nos utilisateurs contre le phishing, n'est-ce pas ?
Ici l'attaque part d'un support légitime, réellement écrit par son auteur : il ne s'agit pas d'un faux message de votre Support utilisateur écrit dans un français approximatif. Non, il s'agit de transformer des contenus légitimes en vecteur d'attaque sans même avoir besoin de modifier ces contenus.

À méditer.

Related posts

Cherche administrateur système

L'université Lyon 2 recherche un admin système H/F. CDD d'un an, renouvelable.
Le profil est détaillé ci-dessous. Si vous avez des questions vous pouvez me contacter.
Envoyez CV et lettre de motivation à la RH Lyon 2

Poste à pourvoir à partir de : ASAP
Affectation Direction des Systèmes d’Information
Localisation géographique Campus Porte des Alpes – Bron
Niveau de rémunération IGE 2 C échelon 5 – 25,3 K€ brut annuels, avec 55 jours de congés
Niveau diplôme requis Bac +3 mini en informatique

Mission : Au sein de l'équipe Système du pôle Opérations de la DSI Lyon 2, vous avez en charge l’administration et l’exploitation des infrastructures serveur physique et virtuelle.

ACTIVITES PRINCIPALES :
• Configuration et supervision des systèmes informatiques physiques et virtuels (VMware)
• Exploitation des applications en production à l’université Administration des serveurs (web,
bases de données, messagerie, etc.)
• Collaboration avec le pôle Support, le pôle Etudes, intervenants et fournisseurs
• Participation à l’élaboration de cahiers des charges dans le cadre de nouveaux projets
• Gestion des incidents
• Veille technologique, évolution, et modernisation

Compétences

SAVOIR-FAIRE :
• VMware ESXi / VSphere / VCloud Director Linux (préférentiellement RedHat), FreeBSD est un plus.
• Outils et procédures liés à l’exploitation des services (supervision, sauvegarde...)
• Réseaux TCP/IP
• Script Shell
• Bonnes capacités d'expression, rigueur, et organisation Anglais technique

SAVOIR-FAIRE APPRÉCIÉS :
• Systèmes Windows Serveur et Linux Debian,
• Outils de métrologie, d’analyse et de forensic
• ITILv3
• Postfix, filtrage antispam, Firewall iptables
• Serveurs Apache, Glassfish, Tomcat, nginx,
• SAN/NAS, LDAP, CAS, Shibboleth, Active Directory, Oracle, MySQL

COMPORTEMENTS ATTENDUS :
• Autonome
• Rigoureux
• Capacité à travailler en équipe

Moyens mis à disposition (matériels, humains, financiers)

Le candidat exercera son activité sur le campus Portes des Alpes au sein du pôle "Opérations" (8 personnes) de la D.S.I. (40 personnes).

Contexte de travail

Champs des relations :
• Internes entre les différents pôles de la DSI,
• Externes, pilotage prestataires, fournisseurs.

Spécificités :
Disponibilité éventuelle lors de la fermeture de l’Université.

Related posts

My take on the MySpace dump

About a year ago, a full MySpace data breach dump surfaced on the average-Joe Internet. This huge dump (15 GiB compressed) is very interesting because many user accounts have two different password hashes. The first hash is non-salted, and represents a lower-cased, striped to 10 characters, version of the user original password. The second hash, not always present, is salted, and represents the full original user password.
Hence, the dump content can be summarized by this :

id : email : id/username : sha1(strtolower(substr($pass, 0, 9))) : sha1($id . $pass) 

It contains about 116.8 million unique unsalted sha1 hashes, and about 68.5 million salted sha1 hashes.

Of course, people who crack passwords will tell you that the unsalted hashes have no value, because then don't represent real user passwords. They are right. But when you crack those hashes you have a very interesting password candidate to crack the salted hashes. And this is very interesting!

After you cracked most of unsalted hashes, the question is: how do you proceed to crack their salted counterpart? Spoiler alert: hashcat on an Nvidia GTX 1080 is more than 200 times slower than John the Ripper on a single CPU core on this very particular job.

I'm a long time John the Ripper user (on CPU), and I'm pretty fan of it's intelligent design. Working on CPU requires wits and planing. And the more versatile your software is, the more efficient you can be. Hashcat sits on the other end of the spectrum: huge raw power thanks to GPU optimization. But it lacks the most sensible attack mode: "single".

Single mode works by computing password candidates from GECOS data like login, user name, email address, etc. So it makes sense to provide a full password file to JtR, instead of just naked hashes. These passwords metadata are very efficient when you want to create contextual password candidates.
The password retrieved from unsalted hash is more than a clue to retrieve its salted counterpart, in many case it's also the real user password. And when it's not, simple variations handled by mangling rules will do the trick.
You've probably guessed by now: I've created a file where password cracked from non-salted hashes are paired with the corresponding salted hash. The known password impersonate the user login, so that with proper tuning John the Ripper will try only this particular candidate against the corresponding salted hash.
Because of a bug in JtR, I was not able to use this attack on a huge file, I had to split it into small chucks. Nevertheless, I was able to retrieve 36708130 passwords in just 87 minutes. On a single CPU core.
In order to find those passwords with hashcat, I had to rely on a wordlist attack with on a GTX 1080. It took about 14 days to complete. No matter how fast your GPU is (about 1000 MH/s in that particular case), it will brainlessly try every single candidate on every single hash. Remember hashes are salted, so each one requires its own computation. If your file is 60M hashes long, then your GPU will only try 16.6 candidates per second (1000/60). It's very slow and inefficient.

Hashcat performance on a file containing 50% of total hashes.

Sometime, brain is better than raw power. Thank you John ;)

More on this topic:
https://hashes.org/forum/viewtopic.php?t=1715
http://cynosureprime.blogspot.fr/2016/07/myspace-hashes-length-10-and-beyond.html

Related posts

Self-hosted password manager: installing Passbolt on FreeBSD

Arthur Duarte CC-BY-SA-4.0

Arthur Duarte CC-BY-SA-4.0

Password managers, or password safes, are an important thing these days. With the constant pressure we (IT people) put our users under to setup a different password for every single registration/application/web site, it's the best, if not only, way to keep track of these secrets. On one hand, the isolated client-side software can be really powerful and/or well integrated with the OS or the software ecosystem of the user, but it lacks the modern touch of "cloud" that makes your data available anywhere and anytime. On the other hand, a full commercial package will come with client for every device you own, and a monthly fee for cloud synchronization, but you have absolutely no control over your data (just imagine that tomorrow the company you rely on goes bankrupt).
Better safe than sorry: I don't rely on cloud services. It comes at a cost, but it's quite rewarding to show the world another way exists.
Disclaimer: I don't give a sh*t about smartphones, so my needs are computer-centric.

In order to store passwords, and more generally speaking "secrets", in such a way that I can access them anywhere/anytime, I've tried Passbolt. Passbolt is an OpenSource self-hosted password manager, written in PHP/Javascript with a database back end. Hence, install and config are not for the average Joe. On the user side it's quite clean and surprisingly stable for alpha software. So once a LAMP admin has finished installing the server part, any non-skilled user can register and start storing passwords.

Enough chit-chat, let's install.

My initial setup was a vanilla FreeBSD 10.3 install, so I've had to make everything. I won't replay every single step here, especially on the configuration side.

Prerequisites:

pkg install apache24
pkg install mod_php56
pkg install php56-gd
pkg install pecl-memcached
pkg install mysql57-server
pkg install pecl-gnupg
pkg install git
pkg install php56-pdo_mysql
pkg install sudo
pkg install php56-openssl
pkg install php56-ctype
pkg install php56-filter

Everything else should come as a dependency.

Tuning:

Apache must allow .htaccess, so you'll have to put an AllowOverride All somewhere in your configuration. You must also load the Rewrite module. Also, go now for SSL (letsencrypt is free and supported). Non-SSL install of Passbolt are for demo purpose only.
Apache will also need to execute gnupg commands, meaning the www user needs an extended $PATH. The Apache startup script provided on FreeBSD sources Apache environment variables from /usr/local/sbin/envvars and this very file sources every /usr/local/etc/apache24/envvars.d/*.env, so I've created mine:

$ cat /usr/local/etc/apache24/envvars.d/path.env
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin

You also need to tune your MySQL server. If you choose the 5.7, you must edit it's configuration. Just add the following line into [mysqld] section of /usr/local/etc/mysql/my.cnf:

sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

This is due to a bug in Passbolt and could be useless in a not to distant future.

Install recipe:

You can now follow the install recipe at https://www.passbolt.com/help/tech/install.
Generating the GPG key is quite straightforward but you have to keep in mind that Apache's user (www) will need access to the keyring. So if you create this key and keyring with a different user, you'll have to mv and chown -R www the full .gnupg directory somewhere www can read it (outside DocumentRoot is perfectly fine).

Use git to retrieve the application code into appropriate path (according to your Apache config):

cd /usr/local/www
git clone https://github.com/passbolt/passbolt.git

Edit php files as per the documentation.

Beware the install script: make sure you chown -R www the whole passbolt directory before using cake install.
On FreeBSD you won't be able to use su to run the install script, because www's account is locked. You can use sudo instead:

sudo -u www app/Console/cake install --no-admin

Same for the admin account creation:

sudo -u www app/Console/cake passbolt register_user -u patpro@example.com -f Pat -l Pro -r admin

Follow the end of the install doc, and you should be ok. Install the Firefox passbolt extension into your browser, and point to your server.

I'm pretty happy with passbolt so far. I'll have to install a proper production server, with SSL and all, but features are very appealing, the passbolt team is nice and responsive, and the roadmap is loaded with killing features. Yeah BRING ME 2FA \o/.

Related posts

Escaping the Apple ecosystem: a view of the setup

Here is a quick & dirty view of the physical and logical setup of my new workstation. The linux part is not finished yet (no drivers for Radeon GPU, thank you Ubuntu), it's a work in progress.

esx
Not depicted: each USB controller sports 4 USB ports (yellow) or 2 USB ports (pink and blue). It allows me to plug few devices that won't be "managed" by the USB switch.
USB devices plugged-in on the switch are made available to only one VM at a time. When I press the switch button, they disappear for the current VM and are presented to the next one.

Related posts