Hacker News new | comments | show | ask | jobs | submit login
KeePass 2.37 has been released (keepass.info)
73 points by Santosh83 10 days ago | hide | past | web | 45 comments | favorite





KeePass is the perfect example of simplicity over complexity. It does exactly what it sets out to do and it does it well. Unlike online services, I trust it wholeheartedly, because it is free software, well-built, simple, and basically a fancy XML parser with encryption.

The less it does, the fewer ways it can break or be broken. The attack surface is tiny compared to, say, LastPass.

You choose your own sync solution, unlike LastPass/the like.

What's the new standard for AES passes? Patch notes mention it but not the number.


If you're on a Mac and care about UX, MacPass is an awesome client: https://github.com/mstarke/MacPass

This person should sell this...



I've been using KeePass for close to a decade now, and it has never let me down.

Great job!


A while back I asked HN if there was any way I could trust an iOS keepass client. The answer was no, on the basis that you have no way of auditing whether the open source code built what’s in the App Store. Nor is there a way of preventing a rogue keepass client app from accessing the internet and exfiltrating your database and password.

Has any of that changed recently?


Wouldn't this be true for any open source application you don't compile from the source?

There's something called deterministic compilation: https://en.wikipedia.org/wiki/Deterministic_compilation

Debian is trying to get reproducible builds for their packages.

I don't know enough about iOS to say anything about that.


How does that help if you aren't compiling?

Because someone you trust can compile and verify that the source they audited matches the binary you got from the app store.

So how do you do this in practice? Do you just send some guy (that you trust!) hashes of all the files on your system and hope that he spots the backdoored binary soon enough?

Perhaps there's some false assumption there that the "app store" will serve everyone a backdoored binary, instead of performing almost undetectable targeted attacks.


What's stopping you from compiling the source on mac?

Ostensibly because then you'd have to deploy it yourself to the iOS device - which is fine for your iPhone but not so easy for your parents' iPads across the country/world.

The fact that I don’t have a Mac.

I went to KeepassXC, so far, it looks better but it starts much slower...

In terms of "trust factor", which is probably among the main concern in choosing a password manager, they seem equivalent, as far as I can see. But KeepassX or KeepassXC is visually better integrated on non-Windows systems. But it's a deal breaker for me until KDBX4 format support is completed for KeepassXC.

It also have this issue that if you start edit a entry, it never auto locks, otherwise great software.

It actually does, if you check the option 'Automatically save after every change' under Settings -> General.

The most interesting features are:

    - Printable Emergency Sheet
    - a function to search for similar passwords

I came here hoping that the emergency sheet feature was an implementation of Shamir Secret Sharing. That would allow you to give a few sheets to trusted people, which they could combine to reveal your password.

You can do that with any number of utilities, though. Why does it have to be built in to KeePass?

True, but they don't seem obviously inter-operable (at least to non-technical users).

The same parameters input into two online SSSS generators: 3 parts( 2 reqd), secret=hackernews yield different parts.

I want to make it easy to recover. Using the same tool to store the passwords and recover the keys simplifies the process.

[1]: http://point-at-infinity.org/ssss/ [2]: https://iancoleman.github.io/shamir/


That's awesome, I didn't know that algorithm!

I was just given a mac at work and haven't figured out how to integrate KeePass with Firefox on OSX. On Windows I was using KeeFox, but I can't find a mac client that include KeePassRPC and the mono instructions didn't make sense. For now I'm using KeeWeb and manually copying entries. Suggestions?

Suggestion: don't use integration. The whole idea has a high risk of security compromise and the plugins I've seen were not implemented well. I use copy/paste or Autotype and don't find it slow to use at all.

So now all anyone needs to do is watch your clipboard? I'm not arguing your approach as I use Keepass in the same way, but I also know it'd be pretty straightforward to snarf my creds if you were able to watch my clipboard.

Not exactly - KeePassXC (and many of the other clients) do try to unset the clipboard. I think this is as much to save you from accidentally pasting a password into your browser's search box or a chat, but at least on OSX / macOS, it prevents a malicious script from using pbpaste to grab the last entry off the clipboard.

KeePass does the same thing by default, but all you've done is create a race condition. Clipboard changes can be picked up by any application that cares to listen.

Autotype bypasses the clipboard. It works well, particularly for those annoying login pages that prevent pasting from the clipboard.

KeePass can do two-channel obfuscation where it mixes both clipboard and keystrokes, but both of these things are trivial to intercept.


I see the Keepass website has finally started to use HTTPS.

Still not using proper version control, though

Does proper version control mean using github or just a git repo or something of that sort? I guess the developer wants to keep it a single dev project (old fashioned but the small project size means it doesn't make a big difference).[1]

[1]: https://sourceforge.net/p/keepass/discussion/329220/thread/0...


"I'm not going to maintain a version control system."

"Having no source code repository (version control system) doesn't mean that KeePass isn't open source."

--Dominik Reichl


Is this being flagged for some reason?

It's way below similarly aged articles with ~5x fewer points.


Is there an ETA for using .NET Core?

.NET Core is for cli or server software primarily. Not for gui apps. So probably not. They'll continue with Mono on linux I think.

UWP is .NET Core isn't it?

The .NET stack inside UWP is .NET Core (for the most part), but the UI stack of UWP is WinRT controls [you can read that as modern COM controls] implemented mostly in C/C++ and directly a part of Windows.

So .NET Core doesn't benefit from UWP UI library, but UWP typically benefits from .NET Core upgrades.


Thanks, that was a good explanation

No, UWP is not part of .NET Core.

The news this week was that it works with .net standard 2.0 but I assume only on windows.

https://blogs.msdn.microsoft.com/dotnet/2017/10/10/announcin...

If keepass were a .net standard library, you could have different front-ends for various platforms. Making the front-end crossplatform is a good goal too. I'm sure you could use bindings to Qt or gtk. There's various native crossplatform front-ends in the works too. See my comments below.


Are they planning on using .NET Core? With no UI?

Making it into a .net standard library would make it more usable. Could more easily embed it into other apps, or hook up various front-ends, and they could keep their existing front-end and just have it link to the new library.

I assume there's plenty of options... Qt or gtk bindings, electron, etc

Looks like Xamarin is building full cross-platform support via XAML

https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/

Avalonia seems like a straightforward reimplementation of WPF that is already usable.

https://github.com/AvaloniaUI/Avalonia

DotVVM is working on electron support, and I work with it already. I like it.

https://github.com/riganti/dotvvm-electron




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: