This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-19
Channels
- # announcements (5)
- # babashka (49)
- # beginners (11)
- # biff (5)
- # calva (123)
- # clerk (9)
- # cljdoc (5)
- # cljs-dev (9)
- # clojure (62)
- # clojure-europe (32)
- # clojure-nl (1)
- # clojure-norway (54)
- # clojure-uk (3)
- # clojurescript (30)
- # community-development (5)
- # cursive (9)
- # devops (5)
- # events (1)
- # fulcro (35)
- # graalvm (10)
- # gratitude (3)
- # hyperfiddle (9)
- # jobs (3)
- # keechma (1)
- # lsp (10)
- # malli (14)
- # off-topic (42)
- # overtone (1)
- # releases (3)
- # shadow-cljs (66)
- # squint (153)
- # xtdb (19)
Not sure the best place to ask this
I have some code that calls (.readPassword (System/console))
to ask for a password.
The problem is this wont work on a remote socket repl connection, presumably by design.
I'm considering allowing the use of a "less secure" option like just calling read-line
after a prompt instead, but trying to fully understand the security implications of that.
From what I understand .readPassword
mainly just prevents echo output of the text while typing.
And I guess it also assumes access to the real system console.
My access to this repl is always via an SSH tunnel.
My current clojure workflow detects a prompt with the text "password" and prevents echoing the text of the next line of input. I imagine this is more precarious than the proper .readPassword
, it probably requires trusting more tooling, and depends on that particular tooling setup.
Are there any other security implications I should consider here?
System/console depends on having access to the console the process is attached to, so not usable remotely
I would follow something like ssh's lead, get a challenge from the server on connect, sign a response to the challenge with a local private key (maybe protected by password based crypto, getting the password then is entirely local) the server checks the signature is from a trusted key
Thanks, so just to confirm, even assuming I'm always using a socket repl via an ssh tunnel (with the same auth setup as I currently use to access the console), and I understand/accept the no-echo text input in my local repl is imperfect, you would still suggest building something to allow the password to be input locally?
it depends what you are doing, if you are just trying to authenticate the repl session, then something key based seems superior
if you are trying to require a password to do stuff in the repl, I think that is a waste of time
echo/non-echo is a feature of the local terminal, not of the stream of bytes being sent back and forth over the socket, so if you want to support it, you will need to add additional control messages to your protocol instead of just shoveling the raw bytes back and forth over the socket
presumably the credentials are required by the program to do stuff, in which case if I had repl access I would just get the credentials the same way programs do instead of doing the password thing
I had this code in a CLI app that reads a password, but also wanted to use it at the REPL during dev (and didn't care if the pw was echoed during dev)
;;; based on
(defn read-password
([] (read-password nil))
([prompt]
(if-let [console (System/console)]
(do
;; only available when running as an app e.g. with java -jar...
(when prompt (print prompt) (flush))
(String. (.readPassword console)))
(do
(println "[WARN] No secure console available, reading via plaintext.")
(when prompt (print prompt) (flush))
(read-line)))))