4

I'm working on a service which in the end will pull sales reports etc from an App Store account. The main problem with it though is that Apple (so far) doesn't have a public API to make this possible so the only way to achieve this is to have the Apple ID and Password in plain form to at least achieve it through scraping.

That ultimately brought up one major security problem: How to store it as securely as possible?

On the technical part, the back-end services of the project will run off of PHP. I've also investigated some different services and libraries but all utilize the usage of a clear Apple password.

I was mostly thinking of having them stored on a separate server with no-login and only accessible from one host and with an SSH key. The service needs to be able to store as well as retrieve passwords.

But it for me still feels as not secure enough as the SSH key would still be on the single host and if it were to be compromised, access to the password store is just a command away.

How would it be most applicable to have clear passwords stored?

Improve this question

2 Answers 2

Reset to default
3

Your idea for a separate server is good. You need to change the interface between the web app and the password database a little. The password database needs to support two operations:

  • Set password for user
  • Get session for user

The password database NEVER reveals passwords. To fetch a session, it connects to directly to Apple, logs in using the credentials it has stored, then returns the session ID to the web application.

Improve this answer
4
  • Hmm yes that is even a much better idea that the session ID only would be returned. But I'm thinking whether that session ID would work on the different server if it might have a different external IP?
    – Karl Viiburg
    Aug 17, 2016 at 14:31
  • @KarlViiburg - Yes it would. You could have the password database fetch the info you need from Apple and only return the data, not the session id. But then there's more code in the db - more chance of a vulnerability. So it's a trade-off - I'd probably stick with what I outlined - but you may have different priorities.
    – paj28
    Aug 17, 2016 at 14:49
  • @paj28 Are you stating that the passwords should be stored as plain text in the DB?
    – Geoff
    Nov 2, 2016 at 22:58
  • @Geoff - Re-read the question: one of the requirements is that the passwords are in plain form.
    – paj28
    Nov 3, 2016 at 11:41
2

I agree with paj28's thoughts. The additional service shouldn't retrieve the password but accomplish the entire thingy you need the password for, i.e. get the session ID or in my opinion even better retrieve the entire reports. In that case if someone compromises the php app (s)he cannot do anything else than getting those reports. Setting the password is maybe a less good idea since this would break the entire security. I set it to something I know and then I have won and don't need the service anymore.

Securing the service with an ssh key brings the same question again: How to store the ssh key securely? I would rather rely on network security, a service listening only on the local interface...

Improve this answer
4
  • I like that idea a lot. So it would make the separate server dedicated to only communicating with Apple. You are also right regarding the ssh key. So with having the server on a local interface, then it should be possible to disable the possibility to log in to the server and then only send commands to it even over plain HTTPS or would something like over TCP be more applicable? For maintenance reasons would having it under VPN and only accessible through office be secure enough as well?
    – Karl Viiburg
    Aug 17, 2016 at 14:33
  • What is the attack scenario that you are most concerned about? The php application has a bug that allows an attacker to gain a limited shell as www-data on the machine? If so, (s)he can download the php code and reengineer how the php app connects to your apple-service. In that case he'll most probably be able to use that service regardless of the protocol. By carefully designing the interface (see discussion above) you can limit the damage in that case. Regarding all the rest: Keep it simple. Important is only that the service executable runs as another user.
    – kaidentity
    Aug 17, 2016 at 14:41
  • The main concern was keeping the passwords safe. But from your suggestion, having it on the local interface (which, if I understood, is like LAN), we could disable login and only issue commands from the web app server (for example: store new credentials, get this accounts sales reports) either over HTTPS or TCP. So the only loss would be that the attacker would get a handful of reports but the credentials would be safe.
    – Karl Viiburg
    Aug 17, 2016 at 14:48
  • keep in mind that setting the password can be as dangerous as stealing the old one. An attacker which is allowed to set the password can still highjack your apple account...
    – kaidentity
    Aug 17, 2016 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.