Keepassium And Synchronisation Can Be Simple… If You Know How To Do It

Almost a year ago I wrote about my lack of confidence in the synchronisation powers of the Keepassium-and-Files combination on iOS. Having an extra layer between my data (the passwords!) and the storage (Dropbox in this case) does seem to complicate matters… especially in comparison to the situation on Android. In the Keepass4Android app there is a button that will do a two-way sync from within the app: you don’t even have to save the data before hitting that sync button.

Today I can say that I have completely mastered the art of syncing from iOS too. The trick, if that’s what you want to call it, is that you have to “exit” the Keepassium file (not the app!) to force the app to update the file and get the Files app to recognise that fact. How do you do that, “exiting” the file? It’s simple: when you’re on the screen that shows you the top level of entries in your vault, you just press “Back”:

See that “Back” option top left?

You’ll return to the “Databases” screen. If you now check the Files app and look for your file, you’ll see that the date and time will be quite current, and you can be sure that your cloud service provider of choice will get that version as soon as you’re online.

What I describe also means that you always have to open file explicitly in order to consult or update it, in order to avoid sync conflicts when changing data on multiple devices. If you don’t do that, you may not be using the latest version of the file since you’re working with data in memory, not in file storage – and that will spell trouble at some point. As a bonus your passwords will also be safer, since an encrypted file on a storage device is much better protected from prying eyes than an unencrypted file in the memory of your iPhone or iPad!

So my general advice is: if you need to read/update/create a password entry in Keepassium, open the file, do your thing, and close the file immediately.

PS. Keepass4Android users should probably do that too, and they should also use that “Sync” button often!

Advertisement

Read Full Post »

For Paranoiacs Only? 2FA Remains A Hard Problem

I’m convinced 2FA is an excellent idea, and I’m already using it for a few situations like my Apple devices and a Google account. Of course I use two-factor authentication on my Apple devices – but that only goes so far, of course. Google also bugs me when logging in to another Google account on those devices, but keeps sending the confirmation to an Android device that I do not always have near me (and I haven’t found a way yet to alter that setting).

But I have always hesitated to apply 2FA to all the applications and websites I use. Why? Because it’s hard to pick the right tool – which one can be applied to most/all sites (and I have a lot of those)? Should I pick a hardware solution, or an application? What about backing up your keys? What if I lose my phone? Etc.

Dan Goodin confirms the complexity of the situation, and tries to give an answer in “Choosing 2FA authenticator apps can be hard. Ars did it so you don’t have to” (on Ars Technica).

Don’t get me wrong: Goodin does an excellent job introducing the complexities of choosing a 2FA solution. But there are many more solutions available – just try any search engine and look for “2FA”. Years ago, I already looked at FreeOTP and andOTP, but I did not feel confident enough in their backup strategies to actually use them. I would also like to know more about privacyIDEA and its application to the problem.

The article mentioned however can be used as a measuring stick, to see whether your 2FA choice ticks the points that you really want/need. And if you don’t use any 2FA solution yet, at least make sure that you have all your (complex!) passwords in a decent password manager on all your devices – I still find Keepassium and the other members of the Keepass family very valuable.

Read Full Post »

How Are You Getting Your Apps Up And Running?

Strong words, but there’s more than a grain of truth in them: “Why Kubernetes is The New Application Server“. “Classic” application servers like those for Java are no longer sufficient by themselves to build a platform that can serve big internet-applications with a large, world-wide audience. And in the world of “containers” Kubernetes seems to be king, as far as I can tell.

(Photo by GPA Photo Archive – Original on Flickr)

In order for containerisation to work, applications must be properly “documented” – in fact, the bulk of the “configuration documentation” will somehow be part of what is needed to get those containers up and running. Around the time I read up on Kubernetes I stumbled onto something called “The Twelve-Factor App” – can’t remember who pointed me there. This methodology (it’s not an app!) describes a well-documented way to build, configure and run a cloud application – a laudable objective.

At work, we have tried to describe our applications in order to migrate them to another (Windows) domain with new (better) rules about access control, database access, etc. But things aren’t working out as they should. We do have documentation, although I’m not sure how useful it is outside of the context of passing relevant information from the developers to an external partner that will implement parts of the configuration. Additionally, we have described lots of “what“s, but almost no “why“s – which might be essential in the coming months and years as the applications continue to evolve…

Ideally, I would have loved to have a decent ‘methodology’ for documenting application essentials when we were building our applications. Trying to figure out what has to be done to get things up and running again on new servers has become something of a nightmare. That is even more so when the application you’re handling was developed by someone who’s no longer available for questioning!

The Twelve-Factor app may turn out to be very useful, although I suspect it is incomplete. I don’t think there is a single method for completely describing and documenting applications and systems that extend beyond the most simple cases. Any ‘methodology’ to build software is bound to need more or less tweaking to fit your (or your company’s) way of working. Getting to know methodologies other than the one you’re using is a good way of discovering what you need to get better!

Read Full Post »

Juggling To Sync A Keepass File Between Multiple Devices

My setup has been the same since quite a few years now: I have a Keepass file on Dropbox, and I use several different applications and apps on multiple devices to access and update that file. Which applications, you ask?

On my Macs as well as on my Xubuntu machines I will use Keeweb. Despite its name, it gives you a desktop application that natively accesses (and syncs) files on Dropbox. This is the application I go to for when I want or need to reorganise the Keepass file, e.g. to rearrange groups or import lots of account data.

I would use Keeweb on a Windows PC as well – if I had one. At work, we have no free choice of which application to use to store passwords, but luckily we do have the “official” Keepass Password Safe at our disposal.

On Android my favourite Keepass app is called Keepass2Android. I will admit that I made that choice a few years ago, and haven’t checked on its competitors recently (are there competitors of note, by the way?). But it does what I need it to do; it accepts Dropbox as cloud storage and it will even merge changes from the local version and the Dropbox version when it detects differences between the two during the synchronisation process. That last one is a killer feature, and it hasn’t failed me a single time in the years I have been using it.

On iOS the situation is a little more complicated – at least, that how it feels to me. I wrote earlier about KeePassium, and that is still my app of choice. I like the interface, and it does all I need when I look for account info (you can store more than just passwords there!).

But in order to sync my central file on Dropbox, on iOS the app has to go through the “Files” app from Apple. Files-the-app is capable of showing files of all kinds on the iOS device, as well as the files on several cloud file systems, like Dropbox. What is less clear to me, however, is how quickly “Files” notices changes on Dropbox and picks up the latest version of my central KeePass file. I also have had trouble getting the latest version of my file (as changed on Android, for example) onto my iPhone. Although I must admit that the last few weeks fared better: I haven’t noticed anymore missing syncs lately. What I can’t say is whether the issue was/is with Files rather than KeePassium or even my internet connection…

Anyway, when it comes to passwords I want to be sure that I’m not missing any information – or worse: I don’t want to overwrite my updated central file with an older version on iPhone! That’s why I currently always check the “last updated on” date of my Dropbox file in Files before opening the file again. Of course my Dropbox account is protected with a password, but I don’t think that is what Andrei Popleteev means when he’s writing about “How to sync KeePassium with Dropbox“.

Manually checking the file date on iOS is not an ideal situation, I know, but to me that check is a small price to pay for the greater good of having my account data available on all the platforms I use! And for me, KeePassium is still the way to go on iOS.

Read Full Post »

Jdrivesync Replaces Grive2 For Google Drive Synchronisation On My Xubuntu Machine

As mentioned earlier, my ‘Grive2’ solution stopped working around November 25, and that is still true today. I have copied the daily updates by hand for a few days, but that is not a permanent solution.

That left me no choice: I needed to find another tool to replace ‘Grive2’. Luckily I had already been experimenting with ‘Jdrivesync‘ somewhere in 2018. The scripts I created at the time should still have worked today (I had kept everything in place), but a first attempt failed with an unclear exception message about OAuth.

Just to be thorough I checked the app access settings on my Google account. I found no sign of ‘Grive2’, just mention of an ‘Ubuntu’ app. So I thought: let’s get rid of that and try again. But that didn’t improve the situation. Strange, because in theory ‘Jdrivesync’ was now supposed to ask for a new authorisation key, and it did not do so.

Looking in my home directory on the Xubuntu I quickly found the culprit: the file .jdrivesync does contain the accessToken and refreshToken required by Google/OAuth. Deleting the file finally did what I wanted: Jdrivesync requested a new authorisation code and ran as it is supposed to do. Nice, although I should point out that Google again complained about not having verified Jdrivesync and did I really want to continue whit that app? Of course I do!

Now I just have to adapt crontab ;-)

PS. I will also keep an eye on the ‘google-drive-ocamlfuse‘ project. That would allow me to mount the Google Drive file system on the Xubuntu machine, giving me an opportunity to learn how to use rsync… But that’s for another time!

Read Full Post »

Google Blocks Grive2 – Or What?

I have been using Grive2 for a couple of years, to help me get the numbers from our photovoltaic panels into Google Drive storage. That has been going very well… until today.

The new or updated files from my panels did not show up today, although they had been created correctly on the EeePC. When I tried the Grive2 synchronisation by hand, the tool reported a 401 error: access not allowed. I suspected an issue with the Apps authorisation for the Google account concerned, so I deleted the existing ‘grive’ App and launched a new registration request. Alas, to no avail; this is what Google had to say:

Why, oh why, Google?

All I can say is: come on, Google! This has been working fine for a couple of years – why cut it off now? If you really had to cut off access, why not alert the its users first? And what is “temporarily”: a day? a week? forever?

I will copy the files by hand for a few days, but that solution won’t last long. After all, we automate processes so we don’t have to remember doing them, the more so when the process is tedious. Copying files by hand is tedious, and error-prone too…

Read Full Post »

Reconnected To LinkedIn…

I tried to reconnect this WordPress blog to LinkedIn tonight, like I have been doing several evenings since my post from a week ago. I saw the error message mentioned earlier multiple times during my trials. This time it worked, just as it should. Let’s hope the situation holds out from now on!

Read Full Post »

Is It A WordPress Error, Or A LinkedIn Bug?

The post on this blog have been “publicized” on Twitter and LinkedIn since many years. Since about three weeks or so, WordPress keeps saying that there is an issue with the connection to LinkedIn. What should be a simple matter of a few clicks and typing a password is turning into something unpleasant. The moment I ask LinkedIn to authorise WordPress, I usually get this message: “Failed to load your request token while connecting to LinkedIn“. LinkedIn seems to accept the request, but WordPress is unable to retrieve the required key and tells me to try again… and again… and again.

I have lived through that scenario on multiple days, so yesterday I hoped to outsmart both applications: I deleted the existing authorisation in LinkedIn, disconnected WordPress from LinkedIn, and then tried to connect WordPress to LinkedIn as if it were the first time I did so. Guess what?

Error message: “The LinkedIn connection could not be made because no account was selected.“

A new error message appeared: “The LinkedIn connection could not be made because no account was selected.” I guess I’ll have to live a few days/weeks without postings on LinkedIn.

Note: I’m doing all my WordPress stuff in a browser on the Mac…

The big picture is a bit disappointing, of course. Here we have to giants on the Web, whose services are explicitly built to be connectable – and then that connection fails. It fails not once, but several times over a period of weeks. It seems as if no one at either company is checking the log files of those applications (it’s hard to imagine that I’m the only one encountering this issue). Perhaps these companies are too big to notice (or worse: care about) such failures?

Read Full Post »

Hey Google! Why Can’t I See And Use My Contacts In The Browser?

This is the wrong time of the year to encounter this problem! I have all my contacts in the Google Mail and Contacts application (GMail) , and when I try to access them in a browser this is what I get to see:

What? No contacts?

I have tried it in Safari and Google Chrome on Mac, and I tried it in Chromium on Lubuntu – all gave me this same white screen. Switching to the network console in Chrome tells me there is a 404 response somewhere in the application…

Am I just the only one that won’t be able to send out my wishes for the new year? And if so, what is provoking this behaviour of the application?

 

Update (4 hours later): you can use this link www.google.com/contacts/u/0/?cplus=1#contacts to access your contacts using the “old style application”…

Read Full Post »