[erlang-questions] Process state and sensitive information

[Tony Rogvall]

On 1 sep 2014, at 23:10, Chris de Villiers <chrisdevilliers@REDACTED> wrote:

> Hello
> 
> I want to make requests to a web service which authenticates users
> with a key and secret.  I will be implementing their API with a
> gen_server and need to place the access credentials somewhere "safe".
> By safe I mean It should be out of plain sight and not accessible to a
> user that can attach to the VM.  I also do not want them to show up in
> stack traces or kernel/SASL logs should the gen_server die
> unexpectedly.
> 
> The application's environment is obviously ruled out.  Storing them in
> the gen_server's state is also no good because sys:get_status/1 gives
> them away.
> 
> I thought about placing them in an ETS table private to the gen_server
> process.  Is it possible for another process to read private ETS
> tables somehow?
> 
private ets tables should be private.


> Any other suggestions how I can handle this situation?  I do not want
> to start a discussion about OS level security.  Lets assume someone
> gets access to the user account under which the VM runs and can attach
> to it.
> 

consider process_flag(sensitive, true).

if you have a "named" service then try find a way of protecting 
the service from a middle-man "attack".

A fun shell example (made super easy thanks to Anthony Ramine) where
a middle-man process prints the first 10 request and then restore the original
process registration.

> Name = file_server_2.
> Orig = whereis(Name)
> MiddleMan = spawn(fun() -> unregister(Name), register(Name,self()), (fun Loop(0) -> unregister(Name), register(Name,Orig); Loop(I) -> receive R -> io:format("request:~p\n", [R]), Orig ! R, Loop(I-1) end end)(10) end).

With some minor hacking the replies could be captured as well.

/Tony

> Regards,
> chris
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"