Make CLI configuration token secure

[roshnet]

Description

Configuring the CLI requires users to specify the token with the --token flag. This causes the token to stick around in the command line history, which can be easily viewed by someone. (e.g. just $ history | grep "exercism configure --token" can bring my token right in front of the attacker)

Solution

It would be safer if the equivalent of Python's getpass library is implemented to obtain input (or just plain STDIN). That way, the token is taken as input from a prompt and is not stored in the commands history.

Additional Notes

Not that it's a huge security risk for users with personal computers, but it would be helpful for shared machines.

[NobbZ]

If one can read a users history, then they probably can read the CLIs configuration as well.

Anyway, I totally support the request, as a lot issues arise when users just copy and paste the full command into a chat or a ticket.

A silenced password (not printing anything while entering) or a "censored" (asterisk or similar instead of characters) would help massively with this.

Though I'd keep the current way of configuring the token as a fall back for scripted installations.

[kotp]

Also, it might be possible to prepend a space before the command to have it not added to the history of the shell, depending on how things are configured.

[byarbrough]

It is a fairly simple change to prompt for a token. The problem is with the unit testing; I'm struggling to refactor the table tests in cmd/configure_test.go to work with inputs to stdin.

I went with fmt.Scanf rather than terminal ReadPassword because the token is displayed on the webpage anyway, and not echoing might confuse new users. Also, it is in the standard library rather than X.