Deploying application with sensitive information in code

  • I'm planning to implement a SMTP client to send feedback from my application to my email and I was wondering about storing the SMTP password in code and how it would be dangerous when it comes to reverse engineering.

    What are you thoughts about that? It's better to use another approach than SMTP, or encrypt the password, or what?

  • I'm far from being an expert here but you could store the OAuth token in your code and use that one instead of a password (for gmail see

  • I'm not familiar with the oauth approach, but isn't it necessary the user to give permission like the window that appears when you try to link an app to your facebook or twitter account?

  • Yes, the idea is that you log into your service (say gmail) you get a oauth token that has permission to send emails, you store it in your app and use it when you have to send emails this way you don't have to store your actual password in your app and if something goes wrong (somebody uses that token to send spam) you can just login and expire the token to shut it down

  • But that is the thing, I want to create a kind of contact form you know? I don't get how this approach is going to help me. I don't want to prompt the browser so the user can authorize the application or something like that.

  • @Mr-Gisa said in Deploying application with sensitive information in code:

    I don't want to prompt the browser so the user can authorize the application or something like that.

    That's not what I meant.

    You (i.e. the developer) log into gmail with a browser and create a oauth token that has the power send emails. You then store that token in the application and send it out to your clients. The application will then use the token instead of an actual password to login to your gmail and send the email to any other address you like.

  • @VRonin I didn't know that it works like that as well, I'll try to see more about that. Thank you.

  • Moderators

    @Mr-Gisa Keep in mind with this approach your token can be used to send emails. So if someone reverse engineered it, they may not have your password but they will have a token they can use to send whatever emails they want using your account. I would still take steps to obfuscate it in your compiled code. Not that you can ever stop reverse engineering of something like that but if you make it hard enough it's not worth the time of the hacker.

  • I was thinking about changing the approach and instead of using SMTP or any other method to send emails to me, I could make the application send an post request to an address in my website like, this way it wouldn't need the password or any other sensitive information in the source code.

  • Moderators

    @Mr-Gisa Much better idea in my opinion. :) Just make sure that feedback page doesn't send email or it will be exploited quickly (in my experience) by spammers.

  • @ambershark Perhaps I could add some kind of captcha in the application somehow to it would avoid the spammers you know?

  • Moderators

    @Mr-Gisa I would just limit it to emailing a static account (i.e. yours). That way a spammer has no reason to use the form at all. Doing a captcha prevents automation which is what you're trying to do.

  • Sorry, but what you mean with that? I don't get it.

  • Moderators

    @Mr-Gisa I was assuming that posting your data to feedback.php would send you an email. It was just an assumption. If the form saves it in a db or some other method than ignore that.

    If it sends an email, just be careful with the underlying code and make sure it's only available to send to your address. I've had hackers attack a webform for emailing feedback on a site I managed long ago, and use it for sending spam. Got my server on a ton of blacklists even though I caught it within a day. It took moving server companies to get my mailing capabilities back from that blacklisting. It was awful!

  • I got what you mean now, thank you for the advice.

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.