Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Bytecode security?, passwords in code?

Author
Message
PartTimeCoder
AGK Tool Maker
6
Years of Service
User Offline
Joined: 9th Mar 2015
Location: Suffolk UK
Posted: 17th Feb 2021 13:44
I am toying with the idea of making this game "semi" online with a direct MySQL connection for the clients but this would mean storing the server login info either in the basic code or compiled in the dll neither of which seem very secure, do I need to use a cypher and just-in-time decryption or am I over thinking the ability's of my potential users?

how would you guys go about this?
Kevin Picone
18
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 17th Feb 2021 14:48 Edited at: 18th Feb 2021 02:29
if you store them as literal strings, they'll be visible in the byte code (and machine code also)..

There's a few solutions, such as encrypting them, but generally I find generating them in code works pretty well. So you'd write a generation routine that actual spits out the creation code to recreate the string.. This can still be peeked tho from a debugger.. but ya get that.


- Make Secret - Convert Password to stupid code

PlayBASIC To HTML5/WEB - Convert PlayBASIC To Machine Code
PartTimeCoder
AGK Tool Maker
6
Years of Service
User Offline
Joined: 9th Mar 2015
Location: Suffolk UK
Posted: 17th Feb 2021 16:22
Yea I guess it has to be viewable at some point, maybe a direct connection is not the best idea after all, the PHP route keeps the login safe but adds a layer of complexity I was trying to avoid and I'd rather just run my querys inside AppGameKit, maybe I need a rethink.
Raven
16
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 17th Feb 2021 19:45
Generally speaking., if someone wants to hack your system... they will.
Now I'd argue a big problem with ONLY using a Database (SQL) is that all of the Authentication Elements essentially HAVE to be in your Application.

This is No Bueno!

Remember, if all of the Security is done locally., then well it can easily be by-passed or recreated for anyone determined enough.
Now what you'll ideally want is a Web Host... if you have a Database then really you should also have a PHP / .NET Core Webhost.

The reason for this is because what you want to do is offload as much of the Authentication process to the Web Host as possible., with all that's being stored locally essentially a Unique User ID to let the Server know WHO is requesting access.
Ideally you'll want to Support 2FA (Google / Microsoft Authenticator)., or even write your own Mobile Authenticator App... but let's say we don't for the moment.

Well, what's another secure approach?
Honestly I'd say a "Whitelist" Approach is actually the best... typically most hack attempts aren't via Trojans, via your own Computer; but instead are Remote Attempts using acquired information.
This means we can actually have a pretty basic approach that will be quite secure.



What we want to do is when the account is first created a Unique Identification Code is Generated; this should be broken down into 4 - 6 Character Segments... and I'd recommend generating a 1024 / 2048bit Code.
This is NEVER sent out., so the only way for the user to get it is via writing it down / printing it out from said Account Creation.

Then when they log-in from a new Device., the Server basically asks them for 3 of the Sequences (as I said you want a big code, say 2048bit, to essentially have about a dozen 4 - 6 Character Sequences)., if it passes then that Device is "Whitelisted"
And another Unique Pass Code is sent... think of this like a "Cookie" Code., so each login a new Cookie Code is generated replacing the existing one.
Instead of typing in your password again., what we do is simply check (a) Login ID, (b) Is it on the Whitelist and (c) is the Whitelist code for THAT Device.

In this respect the password is only ever used when Authenticating a new Device., and what's more is we have crude 2-Factor just to further Authenticate; a bit like the account reset codes a lot of places now do.
Of course once Whitelisted; the password isn't used and those NOT using Whitelisted Devices with the Whitelist authentication won't be able to gain access.

Hopefully you get what I'm saying... of course I'm sure you can think of other approaches, and realistically today I'd ALWAYS suggest just using 2FA Authenticators; because these are incredibly secure (and also don't need you to verify your password) ... so again the password is rarely used / sent but rather an ever changing hardware authenticated one is (which is difficult to brute force).

Login to post a reply

Server time is: 2021-04-11 20:50:43
Your offset time is: 2021-04-11 20:50:43