wneessen / apg-go Goto Github PK

Hey

Nice tool!
I would be nice to have a GIF or usage section with examples in the README 😄

👋

Tracking issue for:

• https://github.com/wneessen/apg-go/security/code-scanning/21

Hello.

Is your feature request related to a problem? Please describe.
Well, I don't see a clear way of requiring at least one numerical or special symbol in passwords. With current flags I can just enable them, but they don't appear in all passwords.

Describe the solution you'd like
Ability to set minimal amount of numerical/special symbols in generated password.

The current apg-go has some design flaws that makes it hard to maintain the code base. To address this, we'll start working on v2 of this. It will overhaul the whole programm and will follow a much more approachable concept. Requested enhancements will be added to v2 but will likely not make it to the current version. The code base will be tracked in the v2 branch.

The project has obviously gone to a lot of trouble to ensure packages, executables and docker images are readily available so it's somewhat surprising that this go project doesn't document the use of "go install github.com/wneessen/apg-go/cmd/apg@latest" as a way of slurping down the latest sources and compiling and installing locally.

The big advantage of the "go install" approach is that we don't have to worry about whether the distributions have updated to the latest versions, particularly if you want to test a recent feature.

I do note that the go.mod requires 1.22 which is more recent than a lot of go distributions (Debian, FreeBSD to name just two) so currently "go install" is a bit constrained, but assuming there is no special need to bump go.mod, as time goes by the "go install" method will work on more and more standard distributions.

Tracking issue for:

• https://github.com/wneessen/apg-go/security/code-scanning/26

The old c-lang version of apg had options -m and -x (for min and max length of the password)

If one used -m 15 -x 20, the generated password was between 15 and 20 chars long.

The new go version prefers -m before -x, so a -m 4 -x 20 will always produce passwords of length 4.

Can the old behaviour be brought back ?

As we all know, entering a random string of characters with a smartphone touch screen is tedious and error prone due to the need to toggle keypads to gain access to different character tables.

For example, the four character sequence "dO#G" requires the follow 10 keystrokes on iOS.

_<shift> d _<shift> O _{<123> <#+=>} # _{<ABC> <shift>} G

(Where _<keypad> identifies a keypad selection).

This makes entering a reasonable secure random password an excruciating process.

One solution is to group the string in keypad order, e.g, all the lower case letters first, then the upper case letters, then the unshifted specials and finally the shifted specials and thus significantly reducing the times a _<shift> keystroke is needed as well as the number of keyboard context switches for your brain.

For example, the sequence "Fj#Wr@eLxP9z]9eL" might be regrouped as "FWLPjwrexze99@]#".

There are probably other ordering sequences which simplify smartphone typing, such as those who type with two thumbs in which case the characters might be alternately selected from the left-hand side then the right-hand side.

Hopefully the benefits are pretty obvious, however there are a number of arguments against the idea:

1. Obviously any predictable ordering reduces keyspace size for a given length, though the grouping order can still be randomized somewhat as well as the size of the group to increase keyspace size a bit. But when enabled, such a feature should probably recommend increasing key length. Having said that, PINs and the other constrained keyspace sets are vastly smaller per character, so it's not entirely doom and gloom on the security front.

2. Different operating systems have different keypads, so it might need to be optioned for Android, iOS, etc. which could change their keypad in a future release. It might get a bit unwieldy if selection has to be made by platform/os/language/version.

3. Some apps on some platforms can select or use custom keypads which might thwart the benefit of grouping in some cases.

4. One could argue that you should just use a password manager which potentially lets you cut and paste. But some of us don't trust password managers (which is why we use standalone password managers like apg!) and too many websites think it improves security to disallow cut/paste for their password fields.

So this is not necessarily a compelling feature, but it might be useful enough to some.

To allow use of apg-go as Go package in other Go applications, the library code and the CLI app code should be seperated from each other.

Since the HIBP code is not really supposed to be part of the password manager, the code should be change, so that https://github.com/wneessen/go-hibp is used for that funcationality instead.

Tracking issue for:

• https://github.com/wneessen/apg-go/security/code-scanning/17

I saw your comment about NIST but would still like this.

Tracking issue for:

• https://github.com/wneessen/apg-go/security/code-scanning/25