How can I secure store strings like passwords in a ktor app?

# ktor

[Łukasz Bednarczyk]

How can I secure store strings like passwords in a ktor app?

[Aleksei Tirman [JB]]

You can store them in a configuration file under security block https://ktor.io/docs/configurations.html#hocon-overview. Here is an example:

application.conf

ktor {
    deployment {
        port = 8080
    }

    application {
        modules = [ AppKt.module ]
    }

    security {
        secret = secret
    }
}

app.kt

fun main(args: Array<String>): Unit = io.ktor.server.jetty.EngineMain.main(args)

fun Application.module(testing: Boolean = false) {
    routing {
        get("/foo") {
            val secret = call.application.environment.config.property("ktor.security.secret").getString()
            call.respondText { "Now, you know my $secret" }
        }
    }
}

[Łukasz Bednarczyk]

IMO it’s not secure 😉 I thought about something like an encrypted Rails secrets

[Aleksei Tirman [JB]]

There is no built-in functionality for it then.

[Łukasz Bednarczyk]

Rocky Jaiswal | Secrets management in a Kotlin application

[Łukasz Bednarczyk]

Someone tried to do this

[MarkRS]

I've been using a library for this, Stringcare, https://github.com/StringCare/

[Todd]

Another option would be to provide the secrets as environment variables and read them using System.getEnv.

[Matt Sponer]

I use AWS Secrets Manager -- and just stick an override application.conf file in it.

This secret configuration overrides any values in the base resources/application.conf bundled with the application.

The nice thing about this is that it's automatic -- the local development environment (or testing in the CI pipeline) doesn't have IAM credentials, so the fetch from Secrets Manager fails -- and so the configuration is just what is bundled in the app.

But in ECS/EC2, the application has IAM credentials and the call to Secrets Manager works, so that secret configuration overlays any fields that it contains over the bundled configuration.

To me it's annoying that Ktor uses Typesafe Config, but then wraps it in their own class while removing a bunch of features and making it impossible to use some nice helper libraries (like config4k, which lets you use data classes for the configuration so you aren't littering your code with magic config strings...). Anyways, if you go back to Typesafe Config, it's easy to load a configuration file from another source (like Secrets Manager), and then "layer" it over the default configuration with the withFallback function.