Lionel: On Wed, Sep 2, 2020 at 5:46 PM Lionel Bouton <lionel.bouton@xxxxxxx> wrote: ... > The software uses a modern version of PostgreSQL (9.6 or later) and uses > a transaction to store a vote and the corresponding register entry in > two separate tables. ...> > There's already an obvious angle of attack to correlate a vote and a > register entry : the WAL. That said the WAL can be configured to be > short lived to minimize the attack surface. By my understanding a low .... > Another angle I could think of are the transaction ids. If I'm not > mistaken they are stored on disk inside the files storing table and > index data (my quick read of the documentation lets me think the txid is ... > Is there a way to access these values by connecting to a PostgreSQL > server instead of analyzing in-memory or on-disk data ? If you assume attackers can read your disks, or even query arbitrary tables, you are going to find plenty of potential attacks. Apart from xid databases tend to lay insertions sequentially on disk, so if your main way of filling the tables is inserting a pair you've got a nice probability of correlating them with just two "select * from voters/entries" ( or just dumping the raw table files if they get file but not sql access ). In fact even paper voting can be attacked this way ( in spain they write every voter in the order in which they vote on a sheet, and if you do not take care to shake the ballot boxes you can get a very decent aproximation to the envelope insertion order ( you will need raw access to the boxes, like you would need raw sql or disk access in your case ) ) . ( Not sure if ballot box is the correct term ) For something like that I would try to insure no disk access, no raw sql access, give the apps a single point of access to the DB mediating every query/operation with a stored procedure/function, using accounts with access to only those, even for selects, so you have tight control and easier auditing. Francisco Olarte.
