Hmm sorry but did u at least checked it ?,
the keys aren't saved online at all, all on ur pc =)
Comment has been collapsed.
mate don't be so rude, well am one of the two people who created this app, it was even my idea , cz i been trading games for a long time now, and i found it hard to store my keys on txt/excel files and manage them , and not lose them,
if you haven't any proof that agrees with your opinion i wish you don't call people just theeves.
Comment has been collapsed.
Oh ok it is just your App screams SCAM from a mile and your way of advertising it does not help it.
Maybe put it on secure trusted store that will check the App before letting people download it instead of putting the app on your website? Maybe try Google store (EDIT: Google Play) because that is where the Apps are and they are checked to not be SCAMs.
Comment has been collapsed.
hmm thanks for your opinion, i just checked google store , (first time i hear of it) , aand it told it isn't available on my country yet
well i'll put the source code soon so can taht help ?;
also i reported & deleted your comment on youtube it was a harassment ,but thanks anyway =)
Comment has been collapsed.
Thanks!
And from what I see you did not deleted my comment. Maybe you just reported it. But it does not break youtube rules.
There is nothing wrong with:
"Great App!
If you are like me and had enough of dogs chasing you or people shooting at you when you break in their house to search their drawers and PC to find game keys this app is for you! I like how it makes stealing of game keys so easy!
Best App 2020!"
Comment has been collapsed.
i screenshoted your comment on my phone mobile, i would hate to post it.
i accept your opinion but not in a harassement way bcz of who i'm =)
Comment has been collapsed.
Sorry but most people don't trust a guy that was inactive for 2 years and then comes back with some glorious great groundbreaking super secure App that can do what simple Google Drive or Google Excel Sheets can do. Also if you are not from a place that Google Store is working that means your App won't be abiding to all the EU and USA laws of data protection and data handling and that makes your App even more dangerous for the users if it handles any data like said game keys.
Comment has been collapsed.
appreciate the effort but so why just not use excel?!
Comment has been collapsed.
@maruten your keys and data are only saved on your pc with your account acess only, it won't save anything online
Comment has been collapsed.
Hmm am not sure what to say , since i didn't really talked much about what the all the app features are,
i wanted you guys to explore the app ,use it, and find that out for your selves,
we didn't develop an app that does excel work, we made an app to store your keys safer and easier,
your keys will be saved on your local machine & on you onedrive account if you wish so, even though you won't be a ble to access taht data on any other pc without your account credentials, so u can use the app on both your pc's (if u have so) & still can access the same synced data
Comment has been collapsed.
Besides being able to see them on both PCs if someone would wish to do so, it still sounds the same as a simple Excel sheet, you can put a password on that as well and let's be honest, unless you share your PC with other people, the chance that someone can get access to any of your files is very very small already. Besides I don't see why using the app would be easier, in Excel you can also just copy and past, , which is done in seconds at best.
To be clear, I don't use any mobile device like a smartphone so I have no use for any apps also don't have any sheets of keys because I just use keys right away to be done with that, I was just wondering why it would be of any more use than an Excel sheet and so far, I am not convinced but if there are people who think it is of any use to them, glad they found it useful but if I had a sheet full of keys, I would just keep using Excel and not get your app for that.
Comment has been collapsed.
i wanted you guys to explore the app ,use it, and find that out for your selves,
Now I'm worried that your app comes with malware on top of possibly stealing keys.
Comment has been collapsed.
I am not a programmer, so I have no way to verify your software. I can only go by what I read in your replies and in the post. ...and that screams scam from a mile away.
Consider changing the way you present this idea of yours, because if I see a really unprofessional demo of some app, that's hosted on mediafire, that want's to store my valuables, has no reviews, is not on any verified online store and looks like one of those antivirus apps that steal your data, I am going to stay far away from your product.
Not to mention, the functionality is basically identical to an Excel file or Google's Sheet, both which already have online features. Unfortunately, there really is no benefit to this app, unless someone really despises the spreadsheet aesthetics. Did you do user research and testing, is this perhaps for big traders?
Comment has been collapsed.
The app is a better way , u can easy search for ur keys etc..
Comment has been collapsed.
i use a discord server to store keys that way i all ways have my keys with me :)
Comment has been collapsed.
"...beyond question"
true - entire thing is so beyond my understanding, that I don't even know where to start question
"a professional trading portal" and at the same time "none of the data will be saved on the web" - impossible
Comment has been collapsed.
possible, there only 2 ways that the app connects to our website:
1st , getting app & db updates
2nd, when u lose your password and ask for a recovery.
Comment has been collapsed.
well the site won't evaporate i assure that, also , u can allways access your keys, no need for my website
Comment has been collapsed.
as a dev, there are a lott of ways to get it back, that we can provide, no need to worry
Comment has been collapsed.
user must read it
password is stored in plain text
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L99
Comment has been collapsed.
I also asked if he has pen-tested his server. He didn't answer the question but assured me security wasn't an issue.
Even if there weren't serious issues with the architecture and implementation and questions to the intentions of this individual, the likelihood that a server's being run that's properly hardened against attacks means it's reasonable to assume at some point the product and data is compromised.
Comment has been collapsed.
How can we be lying if we are looking into your source code and we see how bad it is and how unsafe it is to save any password in this app you created and how it is worse to use than a Google Excel Sheet?
Edit: And anyone can see my comment on Youtube and you said you deleted it and reported it but Youtube did not find anything wrong in my comment and it is still under your video. Anyone can check my comment vs your "screenshot" :) I also love how you asked your friend to like the video to promote this SCAM :)
Comment has been collapsed.
Thank you :). Happy to reciprocate.
I'm reasonably knowledgeable in my space (defensive security and software engineering). And even with that heavy security background, I'd be exceptionally wary of running a server for something like this. It's frankly not worth the effort to properly harden it against attackers who'd have a pretty good incentive to compromise the server if this were ever to get a real user-base.
Comment has been collapsed.
The Saved password there is when you use "remember me"
never seen a browser saving your pws ?
if you don't select remember me, pw will never be stored that way
Comment has been collapsed.
But the "remember me" feature isn't implemented by storing a plain-text password. Properly architected, a "remember me" type feature for something that doesn't remotely authenticate will not store a password at all. It will just store a configuration setting that bypasses the need to enter a password.
If remote authentication were necessary, ideally some other token-based method of authentication would be used so that the secret wasn't exposed. Generally speaking, it's poor form for the vast majority of applications to store passwords even in an encrypted format. Even on the server-side, passwords shouldn't be stored. A one-way hash that is salted should be used to verify the user has entered the proper password when authenticating manually.
Comment has been collapsed.
"remember password" feature is the same on google chrome, so google is using a bad idea to store your keys ? Okay!
Comment has been collapsed.
Google Chrome stores passwords for remote authentication. It has to store passwords because not every site provides token-based authentication.
You said your product doesn't remotely authenticate, correct? So the only authentication data you want to store is the hashed password (salting is unnecessary if you're only storing a single password). I was taking the poster at his word when he said the password was stored in clear-text. Perhaps he was mistaken. Can you link to the section of code on GitHub where you perform the SHA1 hash on the password that gets stored?
Just as a general note from a fellow developer, you should include far more comments in your code. It's important for maintaining your code-base. But it's even more important in this instance where you're making your code open-source so people can verify it isn't malicious. The lack of comments makes it difficult to quickly assess what the program does. The program is complex enough that the architecture isn't immediately evident.
Comment has been collapsed.
He is not lying, password is hashed indeed (without salt):
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L123
But it means nothing, because this password is useless. It's not used for encryption, and only compared on login. Data is not protected in any way.
Comment has been collapsed.
The original password is hashed. But the code snippet that was linked was for the "remember me" feature. Unless I'm missing something, that password is absolutely not hashed and is indeed stored in plain-text.
The save happens here (note that userdata.password is the clear-text password run through SHA1 in the comparison):
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L87-L88
The localStorage.savedpassword that gets stored is that same clear-text userdata.password:
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L99
So when you use the "remember me" function, you're (needlessly) saving a clear-text password. This is a pretty basic security flaw from someone who assured me that the server is secure. I find it extremely unlikely that someone who is unaware of that basic security flaw in the code has taken sufficient measures to solve the much harder problem of hardening the server.
Comment has been collapsed.
You are right, both hash and password are stored, lol.
Comment has been collapsed.
Which means he's either intentionally lying or isn't even familiar enough with his own code to know what it did.
I'm really trying to give the benefit of the doubt here, but he's making it hard.
Comment has been collapsed.
Actually, it does not matters, since this password is not used to encrypt data ¯\_(ツ)_/¯
Comment has been collapsed.
It doesn't matter for protecting the game key data. It does matter for protecting your password (which people often reuse).
Comment has been collapsed.
Yeah, that's a good point. I actually went a bit deeper into that in a comment further down, indicating it technically helps. But if your password is going to show up in a dictionary/rainbow table, it's going to get cracked either way with only one password to crack. You're kind of screwed regardless in that situation.
For a project with this architecture, where the password is only stopping someone who doesn't understand the numerous ways to bypass the little bit of protection it provides, I think you can get away without a salt. But you're right to say it'd be good practice (both coding practice and a security practice) to include it.
Comment has been collapsed.
I took the time to look at your code. You're incorrect.
The "remember me" save happens here (note that userdata.password is the clear-text password run through SHA1 in the comparison):
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L87-L88
The localStorage.savedpassword that gets stored is that same clear-text userdata.password:
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L99
So while the original password data is stored after being run through SHA1, the savedpassword is stored in plain-text. This is a very basic security flaw. One you either intentionally lied about when you said you don't store plain-text passwords or one you were unaware of despite being a developer of the project.
Comment has been collapsed.
am having trouble understanding you & explaining the app or how it works exactly , would you like me to add on steam, so we can voice chat ?
Comment has been collapsed.
Sorry, I don't feel comfortable doing that.
Look at the savedata() function where you store the userdata.password into localStorage.savedpassword. The data stored in savedpassword is not hashed prior to storing it. That means the password is stored in clear-text. This is a significant security flaw that was pointed out to you earlier by MandalorTheDesperate.
Comment has been collapsed.
Sure Np.
Comment has been collapsed.
You're correct that the password will only be stored in plain-text if you use the "remember me" feature. That's not however a valid excuse for having a security flaw in your program. It's one that's easily fixed. There's absolutely no need to store the password (clear-text or not) when you use "remember me" for local authentication. All you need to do is store a boolean that tracks whether "remember me" is enabled. If it is, you skip the entire login procedure.
And yes, I have saved passwords in browsers before. And when I do, those passwords are not stored on disk in clear-text. They encrypt those passwords prior to storing them. That's not something you do when you store savedpassword. So why did you claim you don't store clear-text passwords? Were you unaware that you were storing "savedpassword" in clear-text?
Comment has been collapsed.
All you need to do is store a boolean that tracks whether "remember me" is enabled. If it is, you skip the entire login procedure.
That is just asking for trouble :)
Comment has been collapsed.
How is that asking for trouble? It's functionally equivalent to what's already being done. The only difference is that he's needlessly storing a clear-text password instead of a single boolean.
Comment has been collapsed.
How is that asking for trouble?
It's easily exploitable and leaves you open to various types of attacks.
Comment has been collapsed.
How is it more exploitable than storing a clear-text password?
Comment has been collapsed.
How is it more exploitable than storing a clear-text password?
We're talking about security here not about the lesser of two evils. Both are bad approaches that provide no real "security".
Comment has been collapsed.
How do you propose you implement a "remember me" function for a local authentication in a way that's more secure than what I suggested? The whole point of a "remember me" function is lessening security in the interest of convenience.
Comment has been collapsed.
Let me say this, there isno secutiy if you have the whole program in front of you,u evenhave the sourcecode, soucan bypass the login screen in 1 command =)
Comment has been collapsed.
Which makes it even worse that you're needlessly storing a password in clear-text. People often re-use passwords, so it poses risks outside of using your program.
To be clear, I wasn't asking my questions rhetorically earlier. I'm interested in knowing why you claimed you don't store clear-text passwords and whether you were unaware that you were storing "savedpassword" in clear-text? I took my time to review your code and explain a flaw in it. I think it's reasonable to expect an answer on this.
Comment has been collapsed.
Comment has been collapsed.
In reply to
"Also the password is hashed with SHA1, it isn't stored as a plain text at all" in https://www.steamgifts.com/go/comment/WzTHlLy
Comment has been collapsed.
Read this also :
https://www.steamgifts.com/go/comment/o8FT6mF
don't read only a reply when we were talking
Comment has been collapsed.
That comment doesn't change the fact that you incorrectly stated you don't store clear-text passwords. You might not always store clear-text passwords. But there are instances were you store clear-text passwords. You should have been upfront about that because that is a security risk. Or better yet, you should have designed the product to not have that flaw to begin with.
I've tried to give you the benefit of the doubt. But I've spent my time looking into your code, pointed out a flaw, and you've shown not even the barest hint of appreciation for it or even the slightest concern for your mistake.
Comment has been collapsed.
The whole point of a "remember me" function is lessening security in the interest of convenience.
Wrong. It's about providing convenience without compromising the available security (from a functional standpoint).
How do you propose you implement a "remember me" function for a local authentication in a way that's more secure than what I suggested?
:) Sorry, I'm not teaching systems architecture and security practices in my spare time. I simply pointed out your approach was quite vulnerable. You can search various courses that discuss the subject at large. For instance, a simple post validation timed token mechanism is more than enough to provide the basic security if the architecture is properly implemented ;).
Comment has been collapsed.
We're discussing a local authentication. There is no HTTP post. There is no remote server needed for authentication. The authentication takes place on the same computer that has to store the "remember me" configuration setting.
Comment has been collapsed.
We're discussing a local authentication
No, we're discussing about a security flaw you claimed to be the solution for another security flaw in OP's app.
There is no HTTP post. There is no remote server needed for authentication. The authentication takes place on the same computer that has to store the "remember me" configuration setting.
This is a web app encapsulated as a standalone program build around Chromium and Node.js. Any applicable practices apply to it too.
Comment has been collapsed.
The app has no remote authentication according to the creator: "u can use the app without internet (internet is for app updates & db updates as notifications & password recovery)". With your proposed solution, there is no server to receive a timed token from.
That's the reason I suggested simply storing the configuration setting and bypassing the local check that compares SHA1 hashes to authenticate when using the "remember me" capability. It's going to be functionally equivalent and as secure as any alternative that doesn't have a remote server for authentication.
Comment has been collapsed.
and bypassing the local check [...] to authenticate [...] It's going to be functionally equivalent and as secure as any alternative that doesn't have a remote server for authentication.
Oh for God's sake, are you really serious?
You seem to be under the false impression that you need a remote server to be able to implement a proper authentication mechanism. You don't. The same mechanism can be implemented locally, as long as you have a proper architecture that supports it.
You also seem to be under the false impression that if I proved you wrong I am under some weird obligation to educate you on how to do things the right way. I pointed you in the right direction and took of my spare time to give you free advice that I'm usually paid for. From here on it's up to you to research and better yourself.
You claimed that "I'm reasonably knowledgeable in my space (defensive security and software engineering)" but you lack basic understanding of systems architecture and security practices and continue to claim a critical security flaw as "functionally equivalent and as secure as any alternative that doesn't have a remote server for authentication".
I sincerely hope you aren't involved in any architecting or security development for any commercial application for the sake of its users and the company behind it.
If you think that's not a big deal, I'll give you an example: Yahoo must pay a settlement of $117,500,000 and had around three billion compromised accounts worldwide because people like you took the easy way out and were dismissive enough of the proper security practices.
Being a junior is no shame as long as you learn from your mistakes and continue to improve.
You're fast to point fingers towards others and dismissive and ignorant against any constructive criticism.
Also, thank you for the blacklist as it clears any possible misunderstanding and really proves my point.
Comment has been collapsed.
Yes, I am serious. The requirements of his project given what he described and has implemented:
1.) No remote authentication
2.) A "remember me" feature that indefinitely eliminates the need to enter the user's password to authenticate
An indefinite "remember me" feature with no remote authentication is functionally equivalent to disabling authentication. The user no longer has to enter a user name. The user no longer has to enter a password. The user has made a conscious choice to disable authentication for the sake of convenience.
You can disagree with even offering that as a feature. I'd absolutely agree with that assessment if this project was intended as a secure alternative to what most people currently do: store keys in a text/spreadsheet document. Neither of those alternatives require a second-layer of authentication beyond being logged in as a user with read permissions of those files. But the value proposition the creator focuses on isn't security, it's usability improvements over the alternative of tracking your keys in a document. So if people don't want to opt-in to a second-layer of authentication because it makes the product less usable, offering an option to disable that "security" (you'll note it provides no functional benefit as implemented) feature is reasonable. In an ideal world, he'd communicate that risk to users when they select the option.
There's a balance between security and usability. You proposed a timed token client-server mechanism. I could have made some snide comment about how that's "asking for trouble". After all, it would be far more secure to write your keys down on a piece of paper, create your own unique cipher to encrypt that sensitive data, and store it in a safe deposit box. But that would of course be ludicrous overkill for what is relatively unimportant data that the majority of users store in a completely unprotected form on their PCs/cloud repository currently. And given the intentions of this product, I'd suggest anything more sophisticated than allowing a user to choose whether they want to enable authentication or not is similarly overkill. Especially when the developer has demonstrated both a lack of understanding of how to implement his existing featureset securely and an unresponsiveness to taking the two minutes it would take to fix one insecure aspect of the implementation that was pointed out to him by two different posters.
I blacklisted you for two reasons:
1.) You chose to insult me rather than propose an architecture that fits his requirements that is more secure than what I proposed. If you're willing to hurl personal insults at people, you should be willing to defend your own stance. I cannot meaningful critique a solution you refuse to propose.
2.) I see no posts where you actually communicate any of the number of risks in his design/implementation to the person who made this project and is trying to get people to install it. You've chosen to engage me instead of the person who's putting people's data at risk (not just stupid game key data but other data on the computer as well).
I'll be happy to take you off my blacklist if you apologize or if, instead of insulting me, you propose an architecture more secure than the option I gave him that allows him to change two lines of code to remedy a serious security flaw that needlessly exposes a user's password.
Comment has been collapsed.
You're quite a demanding person aren't you? You wrongly seem to believe I have something against you. I don't.
I didn't insult you, I sincerely expressed my genuine hope you don't do this for a living and I even told you why. Don't take it the wrong way, learn from your mistakes and move on.
You claimed to be a security specialist providing a secure solution for a security flaw and you complained about the effort you spent on reviewing the code and demanded explanations and appreciation.
I pointed out your solution is also a security flaw and you refused to accept it. Despite your dismissive attitude and your false claims, as a gesture of goodwill, I even went as far as giving you a simple example of a post validation timed token mechanism as a better approach and you rapidly tried to refute it on baseless grounds.
To be clear, your solution was to use a simple boolean setting and entirely bypassing any validation and claimed it as being more secure. You don't seem to realize this entirely removes any hint of security. Don't sugarcoat it as an expert advice on how to fix problems.
Also, you don't seem to understand that, from a security standpoint, no "remember me" feature is indefinite. All properly implemented "remember me" functions do some sort of validation beforehand. Your solution provides no mitigation against any type of attacks.
And, to top it all off, now you're demanding me a complete architecture and an apology? Are you kidding me?
Comment has been collapsed.
"All properly implemented "remember me" functions do some sort of validation beforehand. "
I'm hoping this is where there is confusion. Just to be 100% clear on what you are communicating in that sentence, are you saying that a user should have to enter the correct password before the "remember me" feature can be enabled? If so, I agree entirely. I never said anything to the contrary. I said instead of storing the clear-text password, you store a bool in the savedata() function when the feature is enabled. His implementation already correctly required proper credentials before savedata was called: https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L87-L88 . I didn't tell him to change the logic that determines whether the user can enable the "remember me" feature by having properly authenticated during that session.
If you thought I was proposing that a user should be able to click a checkbox on a computer where "remember me" was NOT enabled, not need to enter any credentials, and still gain access to the UI I can understand you thinking the design was flawed. That design would be moronic. But that wasn't at all what I was proposing. My proposed solution was to store a boolean in savedata() that tracks whether "remember me" was enabled and skip the conditional on line 87 if "remember me" had been enabled successfully in a previous session (basically if ((storedRememberMe) || (user==user && password==password)).
If that was the source of confusion, you can ignore the rest below.
"You don't seem to realize this entirely removes any hint of security."
I don't know how you can possibly make that claim if you actually read my reply? I explicitly stated: "An indefinite "remember me" feature with no remote authentication is functionally equivalent to disabling authentication. The user no longer has to enter a user name. The user no longer has to enter a password. The user has made a conscious choice to disable authentication for the sake of convenience."
I'm fully aware that both his implementation and mine "removes any hint of security" provided by requiring a user to type a user name and password before being able to see a UI. I directly acknowledged the fact. It's absolutely the same as not authenticating at all. It was my understanding that this was his intended design.
My suggested implementation of that feature is more secure than his because his implementation needlessly stored the password in clear-text at rest.
Comment has been collapsed.
I think I see why you're not getting it. You're not looking deep enough. Let me put it this way. When architecting a service and implementing security policies you always do it by the following rule "guilty until proven innocent".
As such, a proper mechanism does the following:
I hope you understand the difference between our technical approaches and how deep you need to consider everything before taking critical decisions.
Now, back to your solution, it can be bypassed instantly with or without data tampering. It doesn't matter if before checking the "remember me" option you provided the right credentials. Whatever happens afterwards is wildly exposed and naked to any possible attack. And the funny thing is that it's doable without having to authenticate first. You don't believe me? One can go and directly change that boolean to 1 via a plethora of techniques and gain complete access without any validation, entirely bypassing anything and rendering any authentication completely useless. NEVER use boolean logic for authentication purposes.
Hopefully this clarifies everything.
Comment has been collapsed.
Thank you for a more thorough and thoughtful response. While I agree with much of what you say, I believe the difference in our approaches boils down to security vs usability. You're operating from the mindset that it's inexcusable to offer an option to disable authentication ("There is no "check it and call it a day" and there is no disabling of authentication"), even if that's what the user wants. I disagree with that mindset. And to support that I'm not alone in that belief, I offer up one example as a point of comparison: Firefox.
When I launch Firefox on my Windows computer, Firefox doesn't mandate I login with a separate set of credentials before I can use the browser. I can double-click on the app, and it'll open. I'll have immediate access to the data in that profile. And that data will often contain cookies that allow me to navigate to sites where the user has logged in previously. There are numerous sites with long or persistent session cookies (e.g. Google, LinkedIn, Humble Bundle, Amazon ). I'd argue many sites with long-lasting session cookies have far more sensitive data than some keys for computer games. And yet, the open-source project vetted by numerous experts suffers from the same vulnerability an indefinite length "remember me" configuration does.
Firefox is of course not the only program that doesn't mandate use of a separate set of login credentials. And part of the reason for that is because if you have access to execute the program, you're running from an account that already has read access for its associated data files. I don't even need to use the UI to access Firefox's cookie DB. I can simply load the sqllite DB and read those session cookies. I'm not the only person who knows this. The experts who have created/looked at Firefox are certainly aware of this fact. It's a design decision. Because you only have two choices, encrypt the data on disk and require authentication every single time you use the program to decrypt that data or leave it exposed. They allow the latter because in the former case if the user loses his authentication info, the user loses their data.
The security needs of this program is obviously far less important than an internet browser used by hundreds of millions of people. And yet Firefox still allows for the ability to use their browser without authentication beyond the being logged in as an OS user. Because there are very real tradeoffs (usability and data loss risks) in mandating a separate set of login credentials that meaningfully restrict access to the data handled by the program.
And I believe you when you say there are circumstances where one could change the boolean. But your hypothetical attack ignores some details:
First, if the user can modify that boolean at-rest, they also have read rights to that same data at rest. Which means, they don't need to disable authentication at all. They can literally read the stored data. You could fix that by encrypting the data at rest, but then you get into the situation where users lose their keys if they forget their password (or depending on your encryption algorithm, possibly even if you just have a bad sector on the disk if you don't store the key data in multiple locations).
Second, on a Windows computer the owner of a file always has the ability to write changes to the file (either directly or by modifying the security descriptor if it was changed from Windows default). If an attacker wants to bypass authentication and already is running inside a Windows user's account, all they need to do is change the javascript file itself. This makes a functional and secure "remember me" literally impossible even if you encrypt the data on disk because at some point in that javascript code, the password has to be unencrypted before it can be used to decrypt the other data. You're one console.log away from both the password and the data.
If a hacker has an active session or the ability to execute arbitrary code in the user's account, there's nothing this developer is going to be able to conceivably do to stop them from gaining access to the data. Which again is fine because this program isn't being marketed as a secure alternative to the completely insecure practice of keeping your keys inside of a text/spreadsheet file. It's being marketed as a more convenient alternative. And to remain a convenient alternative, it should offer the ability to disable a secondary form of authentication that doesn't even practically increase the security of the keys given the fact that it's a javascript program.
Comment has been collapsed.
There is no compromise in usability since the end user doesn't notice anything different. Said protection, that can also be customizable to suit individual needs provides no hindrance in terms of usability. Giving up on any protection for simplicity's sake and shifting the blame on the end user for accepting something they might not fully understand is a big NO.
There are many ways to protect against direct data access that can be used individually or in any combination, like virtualization techniques, sandboxing, encryption, etc. Your approach is easily bypassable with or without data tampering even in a bulletproof environment while the other one is not. There are even advanced techniques that can protect the data even if the access is performed by a different person on a fully authenticated session on the origin computer. There's no real drawback in doing things the right way instead of trying to find reasons to justify something bad.
It all boils down to the architect's experience that stems from fully understanding the real implications of their decisions and what practical methods are available to tackle the existing scenarios.
We can split hairs for an eternity and still have things to discuss. There are certain things that are acceptable and others that are not.
We discussed about security, what's more secure and what's vulnerable. So from my perspective it's already Q.E.D.
Comment has been collapsed.
If you have to re-enter the credentials at any point, the end-user absolutely does notice. I sure would notice if suddenly Firefox demanded I enter a password every time/every other time/every 100th time I opened it. And it's a compromise in usability. I don't understand how you think it's acceptable for Firefox to not require a layer of authentication beyond OS user credentials but this small project with low-value data absolutely has to. Or are you criticizing Firefox's design too? Chrome's design? Edge's design? All of which handle even more sensitive data, all of which can be run without secondary authentication.
"Giving up on any protection for simplicity's sake and shifting the blame on the end user for accepting something they might not fully understand is a big NO"
Do you use wireless networks ever? Because a wireless network gives up a significant amount of protection for simplicity's sake. Or for that matter, why even have network connections at all? Or USB ports? Or any number of other attack vectors people have to make things more usable. I feel silly having to point this out because we're discussing implementation of a "remember me" feature. A feature that by its very design exchanges protection for the sake of simplicity. If you truly felt this way, you wouldn't be arguing any timed-token architecture. You'd be arguing every product that has a "remember me" option or no secondary authentication is apparently written by morons.
Every programming projects is going to have some strict requirements. Many of these requirements are going to result in a less secure system. The onus is on the architect to work within those constraints to create a system that is secure as it can be given those requirements (while also taking into account usability, talent-level of the developers, and amount of effort needed to implement/test/maintain that architecture). Designing a secure but unusable system takes little expertise and no ingenuity.
You told me I didn't think deeply enough about vulnerabilities. You said my implementation was vulnerable to someone simply modifying the boolean value stored on disk to bypass authentication. That seems like a strange argument to make. Not only for the reasons I listed before but because of the implicit suggestion that your proposed architecture is better. You had an entire night to think about it. Did you think deeply about this and realize your own solution is vulnerable in exactly the same way? Because you didn't mention that in your response today if you had.
If you store the boolean value in the same datastore that the SHA1 hash of the password is stored (with whatever controlled access, tamper detection, etc), it provides exactly the same amount of security. If a user can edit that datastore to change the boolean value that disables authentication, they can also change the SHA1 on disk that's used as the basis for comparison. It doesn't matter what the user's password used to be. If I want to access the data, I change the SHA1 on disk to whatever password I want it to be. Now it's irrelevant if you introduced timed tokens or other similar mechanisms. I have the actual credential used to authenticate to get any one of those secondary mechanisms.
You can't say I don't think deeply enough about something and then, when I dive down into the OS-level/language-level details that informed my architecture, describe that as splitting hairs. You're suggesting an alternative implementation that increases architectural complexity, disallows a feature that appears to be the developer's intention (an indefinite "remember me" that is a usability feature that is certainly no less secure than Firefox not requiring any secondary credentials at all), and does very little to improve security.
If you don't run a pseudo-server in a separate user account (a usability nightmare), Windows ownership permissions invalidate all security advantages of your architecture. Even if you run that pseudo-server, a user has access to that key data any time the timed-token is active. Which if the "remember me" feature is providing real value is a substantial amount of the time. And even if an attacker only gets access to the computer during a time when that is expired, all they need to do is change the javascript code to do an HTTP POST of the keys to their server/some forum/pastebin/etc the next time the user uses the product because the users of this product are exceedingly unlikely to be doing source code review on it every single time they launch it. But I'd agree your architecture could indeed be more secure for a person who runs a pseudo-server in a separate user account, is frequently timed out of that saved credential, and performs a code audit on the program every time before running it. Though I guess I'd question what sort of person is that paranoid but downloads and runs this to begin with.
All of that might I might just brush off if you hadn't also declared that I'm terrible at what I do and apparently the kind of person that is to blame for Yahoo getting hacked by a nation-state actor. If people like me truly are the reason for the Yahoo breach, that's almost certainly a comment on the attackers being like me (though with an offensive area of focus and presumably more talent) not some deficiency of the defenders.
Comment has been collapsed.
You had an entire night to think about it. Did you think deeply about this...
Are you serious? I hate to break it to you but the world doesn't revolve around you. This is so weird that it makes me have serious concerns about you as a person before you as a self proclaimed security expert that deems users paranoid for expecting common sense from developers to protect their data. As such, I'll cease any further communication.
You're suggesting an alternative implementation that ... does very little to improve security
Wow, I can't believe after the whole discussion this is your conclusion. I've been more than patient and tolerant and explained things in an extremely detailed manner. My bad for giving you the benefit of the doubt.
If you want to be the flat-Earth believer of the pseudo-security field, be my guest. I wish you all the best.
Comment has been collapsed.
There's a reason you didn't answer the questions I asked. If you engaged in a legitimate dialogue you'd have to admit you said things that were indefensible.
I wasn't asking you rhetorically if you've ever used a wireless network. I guarantee you've violated the laughable rule you suggested here that "Giving up on any protection for simplicity's sake and shifting the blame on the end user for accepting something they might not fully understand is a big NO". I'd bet you've used a wireless network despite it being less secure. Or that you don't log out of every single website the moment you aren't interacting with them. Or that you don't use an application whitelisting product. Or that you've saved a credit card on a website to reuse it later. Or any number of other ways you've chosen convenience over security in some small or large way.
You have no answer for why Firefox/Chrome/Edge which have access to far more sensitive data than this app are allowed to run without secondary credentials but for some reason this little app absolutely must have secondary credentials enabled at all times. Because there is no valid answer.
You have no response for why you chose to point out a "security flaw" in my implementation that your implementation also suffers from. I'm still not sure if you just didn't see that same flaw in your own design or was hoping I wouldn't notice that write access to the datastore renders your security measures meaningless.
You also don't appear to have an understanding of the way owner permissions work on Windows with regard to security architecture in a single user account. You seem to be oblivious to how easy it is, especially with a non-compiled program, to render any non-remote security feature you implement utterly meaningless if an attacker has an interactive session or is running arbitrary code. Windows permissions allow that attacker to literally just change the stored password's SHA1 on disk to whatever they want. Or change the javascript. Or read the data right off the disk. Or install a HKCU Run/Startup program that waits until the user has logged into the program and steals the cookie. Or any other number of exploits that cannot realistically be defended against when you give an attacker free rein of your computer through some other security hole. I described this for you patiently, and in detail, and you seem unwilling to acknowledge that this has a significant impact on the practical security of your proposed architecture (well at least to the extent that you even offered one).
Though to be fair, I took some time to think about it and will admit your design was more secure than mine in one way I hadn't previously considered. There's no risk of keys being stolen if no keys are ever entered into the app - either because the developer never finished the app due to a needlessly complicated architecture or because users didn't want to accept the onerous requirements of running the app across two different user accounts in order to get any security advantages because of the way permissions work in Windows. Security through irrelevance.
Comment has been collapsed.
Now I think you're actually trolling. There's no possible way someone can come up with all this nonsense after actually reading what I wrote so far unless it's deliberate. I have to admit you made me take you seriously. Once again, my bad.
Comment has been collapsed.
I'm not trolling.
If you legitimately believe you're right, certainly you are capable of answering one question: Why is it acceptable that Firefox doesn't require you to enter a user name and password before opening the browser but it's unacceptable to give users an option to skip entering a user name and password to open this app?
Comment has been collapsed.
Fine. Firefox will ask for the master password on each startup when using Sync. Happy?
Comment has been collapsed.
You're aware Firefox Sync isn't mandatory, right? You can run Firefox without ever enabling Sync. A user has to consciously opt-in.
So I'd ask again: Why is it acceptable that Firefox doesn't require you to enter a user name and password before opening the browser but it's unacceptable to give users an option to skip entering a user name and password to open this app?
Comment has been collapsed.
You're aware this is the same exact mechanism I described when dealing with sensitive data, right? And it's implemented right in your beloved Firefox that you're randomly using as a fallacy to prove your point. And it's not opt-out once dealing with said sensitive data is in effect. Q.E.D.
Comment has been collapsed.
You're not answering the question. Maybe I'm being unclear. Let me try again.
1.) Sync is not enabled by default. If we're calling Sync a security feature, then Firefox is insecure out of the box. A user must opt-in to security and can opt-out again later. When Sync is disabled, it is disabled until you explicitly make the choice to enable it (that is to say indefinitely).
2.) Logging in is enabled by default in this app. If we're calling this rudimentary type of login a security feature, then this app is secure out the box. A user can opt-out of security and can opt-in again later. When login is disabled via "remember me", it is disabled until you explicitly make the choice to enable it (that is to say indefinitely).
You're calling #1 acceptable. You're calling #2 unacceptable. Please explain why #1 is acceptable if #2 isn't.
Comment has been collapsed.
Exactly like I said: Trolling. I already explained how you don't have to disable security to implement a "remember me option" and you're insisting "But I want to". Then do it. What keeps you from doing it?
Comment has been collapsed.
I'm neither trolling, nor am I the one who won't answer the question.
Firefox "disables security" indefinitely out of the box. It also "disables security" indefinitely when you go into configuration settings and disable Sync (for those users who had previously enabled it). How is this acceptable? This clearly breaks your "there is no disabling of authentication" rule. Is everyone who has worked on this open-source project used by hundreds of millions of people unaware of your better way that makes disabling of authentication entirely unnecessary and an inexcusable security mistake?
As for what keeps me from doing it, well first of all it's not my project. Second, I was willing to entertain a discussion of the architecture. Which did at least get me to consider something I wouldn't have previously with running the app in two separate pieces in two separate user accounts. It's not really a practical solution, but it was at least an interesting thought-experiment for how to get additional security given the constrictions Windows permissions put on practical security measures.
Comment has been collapsed.
Yes, in the mechanism I described there is no disabling of authentication and said authentication is handled in the background. Call it internal validation if it's easier for you. What is so hard to understand? You have a fixation on Firefox and a similar mechanism is loosely implemented in Firefox too. If Firefox says you must starve for a week before accessing SG will you do it? Give me a break with your fallacies.
Comment has been collapsed.
This isn't about Firefox. Firefox is just a single example I selected as a point of reference so we could focus the discussion. I mentioned Chrome and Edge as well. Both of those have un-Synced, non-authenticated modes of operation by default as well. My point was my proposed model is an accepted model, even for applications that handle far more sensitive data than game keys.
Not having a secondary set of login credentials when you launch an app exchanges security for usability. That's a tradeoff that each of those 3 major browsers makes by default. Offering the same lack of security for convenience option in this app is an acceptable design decision, and one that you can't criticize unless you are also willing to criticize Firefox, Chrome, and Edge as well.
Many people don't want to be bothered with entering their password every time they do something because it makes things less efficient. If offering that convenience is some unforgivable sin that would only be committed by people with no understanding of security, can I ask you why you are part of this site? Certainly you must have noticed that when you're logged into this site and go to your "View Created" section, you're not prompted to login again. Despite the fact that the page allows you view unredeemed keys for active giveaways. This site does not meet your security standards, yet here you are.
Comment has been collapsed.
can I ask you why you are part of this site?
Surely to have this discussion with you. Why else?
Comment has been collapsed.
Seriously though. You're saying it's common sense to require re-validation any time sensitive data is accessible when using a product. You obviously consider game keys sensitive enough data to meet this requirement. This site doesn't force you to re-enter credentials when you go to "View Created". Therefore this site isn't implementing what you consider common sense security measures. Why are you using an insecure site?
Comment has been collapsed.
I wouldn't have previously with running the app in two separate pieces in two separate user accounts.
I didn't say that. You just assumed it like many other things. I said the app can be virtualized, sandboxed, encrypted or any combination.This mitigates the direct code access but doesn't protect against other attacks like cloning (even if the direct access is mitigated) unless the internal validation is in effect. This implies the virtualization is done at the encapsulation level not ran by the user in a VM of his choice.
Now write a 10k words essay on how the Sun affects the electromagnetic waves that can result in an EMP that can corrupt or destroy the HDD and its sectors thus rendering the technical approach unfeasible. Give me a break.
Comment has been collapsed.
I know you didn't say that. I was trying to take your model and see if I could use it to increase security given the way permissions work on Windows. That was the only approach I could come up with that offered any sort of advantage in a situation where an attacker has an interactive session or can run arbitrary code in the user account the "client" portion of the app is installed on.
If you design your app properly, there's no chance of a remote exploit being performed on the app. Which means your data is at risk because an attacker exploited some other security weakness to gain an interactive session or the ability to run arbitrary code. Let's take the simplest example. You've installed this app, you walk away from your computer, and you forget to lock the computer. I walk up to your computer. If I want access to your keys through the UI, even if you haven't clicked "remember me", all I do is edit the javascript file to skip the login check. Now I have access to your keys through the UI. Sandboxing doesn't stop that. Virtualization doesn't stop that.
The only way to actually secure the data is to encrypt the data on the disk with that password. But if the user forgets the password with this approach, their keys are lost forever unless you include a backdoor of some sort (which is effectively re-introducing the security vulnerability you were attempting to solve). This is a risk many people would be unwilling to take.
Comment has been collapsed.
If I want access to your keys through the UI, even if you haven't clicked "remember me", all I do is edit the javascript file to skip the login check. Now I have access to your keys through the UI.
Not if the app is running from inside a custom VM.
But if the user forgets the password with this approach, their keys are lost forever
And if the user gets into a car accident those keys might be lost forever.
Comment has been collapsed.
Sure. If you run a custom VM where a user has to explicitly login within a different set of credentials, then compromising the physical host may not gain you access to the keys (assuming the VMDK/VHD files are encrypted). So now I have to login to the physical machine, the virtual machine, and the application itself to use this program. And if I forget the VM password and possibly the app password (if encrypted inside the VM), the keys are lost forever. You can't just dismiss that when designing a product. People forget passwords all the time. It's a legitimate concern when architecting a product.
Beyond that, I also have to have virtualization software on my computer and a valid Windows license in that VM to use this Windows-based program. You've taken an already niche group that would even be interested in this to begin with and further whittled it down by introducing a set of requirements to use the program that make it more complicated and inefficient.
You're basically "encrypting" via virtualization. If you're going to run it in a custom VM, why even have authentication provided by the app at all? And if you are going to have authentication in the app, it'd be simpler to just encrypt the data on disk if that's what you want to do and skip the VM entirely. It's similarly secure against someone having an interactive session. And similarly vulnerable to data loss.
Comment has been collapsed.
Far from it. You still got it wrong and made lots of wrong assumptions as usual. Anyway, the journey will end here. Have fun with the app. And Firefox.
Comment has been collapsed.
I wouldn't have to "make assumptions" if you were actually explicit about your architecture. It's hard to discuss your design when you don't describe it in actual detail. And it's impossible when you somehow hold it against me for attempting to fill in the blanks you could have filled in yourself. That's not discussing in good faith.
You've spent this much time talking to me but haven't taken the time to articulate the details of one model you profess is secure. If you have a more secure model, fill in the details. But when you've dodged actually fleshing this out meaningfully, it leads me to believe you don't actually have a fully-conceived design. "Just run it in a custom VM" leaves out basically every critical implementation detail (are the VMDKs/VHDs encrypted, do you need to explicitly login to the VM, does the app encrypt the data inside the VM as well, etc).
Comment has been collapsed.
There's absolutely no need to store the password
Well if he had indeed encrypted his DB this would be necessary step to save password. But obviously saving password would make whole encryption useless. At the very least it should be used in some other storage, not in the same DB.
Comment has been collapsed.
the account is required to access the app where your keys are stored , so no one can access them even on your pc without you login,
the path on windows is home\OneDrive\GameKey
all ur data can be stored on your onedrive account if you chose so
Comment has been collapsed.
Hmm well i feel you, and i'll consider posting the source code
Comment has been collapsed.
I tryed the app. It's a very good app to use. Easy and friendly gui. You guys should try it. I stored my resident evil 3 key there, that way I know no hacker is gonna get it.
One thing i discovered, this doesn't store only steam keys! This stores also crypycurrency keys! I stored my bitcoin master key there to! I am now safe from bad hackers trying to steal my bit coins!
Comment has been collapsed.
Roll up roll up folks. We've got one hell of a deal for you!
This 19th Century Bridge is made of pure steel, yes that's right folks pure 100% steel. Located over the Sahara river, this bridge is being taken down to build a new bridge out of more sustainable materials. To fund this we're selling this bridge for the knockdown price of all of your Steam keys! Just put your keys into our special program and we'll send your bit of the bridge in the post.
Comment has been collapsed.
Help! I moved all my keys from my excel file to this app, and when I did, the app crashed, and now I can't access it anymore! Before it crashed a message came up that said all keys have been stored securely on TheKiLLerDz' server, and so I don't need to worry. But I don't know how to access the server, and I got a call to say that I had a virus on my windows machine, even though I have a Mac, and now I'm confused. Do you have a contact email I can get support for your app?
Comment has been collapsed.
am not sure why u lie out here,
the app for mac isn't available
but thanks for lying =)
really disappointed
Comment has been collapsed.
' I got a call to say that I had a virus on my windows machine, even though I have a Mac'
Haha... that reminds me of the one call I had with a scam 'windows technician'. I always like to string them along, so the guy phones, usual story, 'This is windows technical services, we are seeing a lot of errors on your microsoft windows PC, can you press the windows button + r and type this'. So I said, 'Sorry, I can't see a windows button anywhere.' He tries to explain a few times and then gives up and calls his friend/supervisor, who then tries to explain a different way to bring up the 'run' dialog. Eventually I tell them that, I'm actually running Mac OS. So then the guy goes, 'Oh ok, here's what I need you to do then'. So I say 'But I thought you were a windows technician?', and he gets angry and says 'What? When did we say that?' and I said, 'Well right at the beginning when you introduced yourselves'. Long silence and then they hung up.
Jokes on them though, I don't even have a mac...
Comment has been collapsed.
yeah i talked with my teammate, and we agreed to make it open source ,
we will anounce it in an hour or so
Comment has been collapsed.
Comment has been collapsed.
"as i trader i met with a lott of problems, i even lost all of my keys once when my hdd burnt."
That does not sound like someone qualified enough to make any App let alone a safe App if you don't even know how to store your keys on USB drive, external drive, or never heard of Google drive or clouds.
Comment has been collapsed.
localy and on you onedrive if you want it to be,
u can access the db on other pc's if u have the same onedrive account there, but ofc u'll need you login credentials
Comment has been collapsed.
i think u know who are the qualified people , sorry for not being one
Comment has been collapsed.
No, but I spent my honeymoon there a number of years ago, Arenal region. Lovely country!
Comment has been collapsed.
needs to use an account while its an "Offline app"
is safer in which way to abuse & scam?
so you just gotta get into the databank and get millions of free keys .
From all of your comments ,your app seems more scam than those shady russian people send me on occasion on steam
Comment has been collapsed.
needs to use an account while its an "Offline app"
i'll answer this part :
the account is for accessing the app, so no one else can access your keys while you gone in anyway unless he has ur login credentials
also the account is used in purpose if you want to access the data from another pc, u only need onedrive account connected & your login info & the app ofc,
i didn't make the app db saved on my side so it won't be assumed as "am steeling them" but it's stored on your PC , and onedriver if you wish.
Comment has been collapsed.
So its not stored on your side but you can click forgot passsword to send it
every word you just said is the opposite you said before .
i guess you can atleast learn about that for future projects ,because i wouldnt install that even if i get paid for it .
Comment has been collapsed.
forgot password, will generate a new password for you, and it will be sent to your email, the only thing am getting here is your email and username so i can send you the new login info.
Comment has been collapsed.
so that means you can also access my stored key file if and when you wish, since you have my login details or have the ability to reset it?
Also if the login thing is for security purpose only, there's no other perks to use the app other than the neat UI or the import feature. I mean if i need to lock my text file or excel file that contains my game keys, i might as well use an encryption tool
also if the login part is server side, then you may have created bigger problem than solving one
on a side note, it takes a fraction of a sec to upload a text file
Comment has been collapsed.
i don't have the direct ability to reset anything, u need to request a password reset from the app , so i can send a new one, i won't know your old pw not you other data (only username, & email are sent to the server).
also * The Login Part isn't sever sided, as i said all on your PC, only when u ask for new password then u'll need to contact my server
Comment has been collapsed.
There is a good app for this - GKeyBank. I use it for... 3 years?
The app works offline (but need internet to download the current game list from steam API)
There are subtitles available (in Polish language, use translation to your language)
https://www.youtube.com/watch?v=ETUpOmRs41k
I also created a written article - on top-right, you can select language.
http://hakimodo.pl/2019/11/18/t25-technicznie-gdzie-trzymac-klucze-steam-gkeybank/
Comment has been collapsed.
Source code will be published, hope u can check it out =)
Comment has been collapsed.
yes am one of the app authors, that is mentionned on the website and on all the websites u can find i think, am not hiding that.
Comment has been collapsed.
You say the Keys are password protected - you also can create an archive with a passowrd. And the argument that I can't lose my keys... You say, the keys are only stored on my PC, so it is just a file, just like an Excel-file. You could lose both. So, where is the point of the app?
Comment has been collapsed.
Comment has been collapsed.
I have to type my password one time to get the archive opened, and if I change one of the Excel files and save it I am asked if it should change it in the archive as well - without asking again for the password. And even if I woul use your app I would enter the password manually, so that isn't so much work more to do without.
It is stored in a cloud, and I think we don't have to talk about security topics. :) But that aside, I hope it is synchronised every time I save the file on my PC - if I have chosen the cloud save.
With Excel you can sort titles alphabetically, so it isn't that kind of a problem to find a specific game. And you can use Ctrl + f.
Don't get me wrong, I don't say that you want to steal keys, I only want to know the practical use of the app.
Comment has been collapsed.
Comment has been collapsed.
Ok, but I'm not a fan of saved login credentials for obvious reasons.
Maybe, but I have never used the IDs of a game, I sort them alphabetically. But with Excel you also can add a column with the ID and search for this instead.
Which features do you mean? I am curious. :)
Comment has been collapsed.
adding them manualy ?; well let me say everything the app offering u can do it somehow ,
the app only makes that easier it ain't offering something extraordinary , it only makes the needed t time shorter
Comment has been collapsed.
So the app ain't for you, maybee
Comment has been collapsed.
I never said that you forced anyone to use it. :) But when I - as a trader - buy keys for trading, I have to add them to the list/app anyway so I also could lookup the ID. Maybe, when you trade in huge amounts it is easier when the app does lookup the ID for me. But then, the app must have access to the steam database.
Comment has been collapsed.
yes it has access to the steam database , we used steam api's to get the list of games
Comment has been collapsed.
And I think that is a point for many here to be sceptical. Who tells us that noone "listens on the connection when the app checks the database? I don't say that you do, but it is technically possible and people don't want to lose their keys.
Comment has been collapsed.
Agreed that's why source code is open,
that's why there are manyways to check that even without the source code , programers can check
Comment has been collapsed.
yes if that's what u mean,
the steam databse of games is stored on your pc when u first open the app, also we will notify you that there is a db update that u can do if there are
Comment has been collapsed.
Mate, I'm sorry, this all probably isn't the reaction you were hoping for. And that's a shame if you really went to the trouble of putting together a fully functional app just to help people store their keys. I appreciate effort like that. But I'm afraid I'm not going to use this.
You have to think of the decision from our point of view: any advantage this app offers offset by worries about reliability and security. Right now, like a lot of folks, I use a spreadsheet. It isn't perfect, but it allows quick sorting by various traits, security, and access from multiple machines. (I use Google Sheets so it's easy to access from all my devices.) I can be quite confident that this will work and that my data, once stored, will be there when I want it. Google's valuable reputation rests, in part, on giving me this confidence. But if I switch to a new app I have to worry about whether this is the case: might your program have a bug and drop entries? Might login authentication fail? Might your servers go down? I have no way of knowing. And why put myself in a position to be hurt if the answer is "yes"?
On top of that, as much as it seems mean to say, I have to at least acknowledge the chance that you're scamming. You don't seem like you are, but how can I know? I would lose property of some value if I decide to trust your program and it does turn out to open my keys to theft. Even if the possibility is fairly remote, what reason to I have to accept the risk? And, honestly, I am puzzled, like others, as to why a program that stores my data locally needs an online account for authentication.
Comment has been collapsed.
I really Appreciate you opinion, thank you =)
Hmm Agreed but you'll never know unless you try.
The Account is offline also, it isn't stored on our servers at all.
I agree with you that there are a posibility of me being a thief or something but i just put the source code so you all can check it out
Maybee you won't use the app this month ,this year, but i hope u'll use it someday & it will help you =)
thanks though =)
Comment has been collapsed.
Do we need an internet domain? How can we use it without internet
Btw ive just loose one cd key for this dlc https://steamdb.info/app/1208250/
Seems like your program din't save it.
Or you just stolled ..
I think you did !
How i can report this?
I've just been scammed ...
Comment has been collapsed.
Comment has been collapsed.
Well my cd key was removed from your "app" after i've added under different name .. explain (I used on my VirtualBox). My cd key was there when i closed your "app" but when i oppened again just disapeared! I think i will report you on SteamRep
Comment has been collapsed.
Sorry but i don't really get you, you won't lose a key only by closing the app.
Comment has been collapsed.
dude give me a break , please if you didn't use the app
just don't say u used it
(if you really used it, & that happened it's a bug that heppened only on your PC bcz i've been trying this app for a while now with some friends)
Comment has been collapsed.
can u send a video about it, or just a screenshot proves taht u used the app =)
and i'll be glad to answer you
Comment has been collapsed.
I'm sorry but I don't think I'll use it. What I told you happened. Do you want evidence?(How do you want to prove it when I no longer own the cd-key?) Try it and see . That's why I don't recommend anyone to use it .. People who want to store their cd-keys can simply save them in a text file. Or use this one https://www.steamgifts.com/discussion/gcPnz/gkeybank-first-release-your-next-tool-to-manage-your-keys-collections
Comment has been collapsed.
Thanks for your opinion, i never asked you to though =)
Comment has been collapsed.
Built With
Electron
VueJS
Vue Router
Http Vue Loader
Vuetify v1.
Vuetify v2.
IndexDB Dexie
readlines
json2xls
read-excel-file
Oh my god, what an abomination is that. Even if I needed an app to keep my keys (I don't) I would never use such a bunch of crap. And secure storage that need online authentication, really? So if you one day decide that you don't want to keep your servers online all users instantly&forever lose all of their keys? What a brilliant idea!
Comment has been collapsed.
Comment has been collapsed.
Yes, if something is crap I call it crap. And it has nothing to do with other programmers. I'm a programmer myself.
You don't need online authentication , where did u get that from ?
Then would you please explain, how is that possible?
if you forgot your password ,we'll provide a new one for you, all u have to do is click "forgot password" on the login screen,we'll receive your email, and * Your username, and then we'll send a new password to your email.(u can change it later).
If it's an offline account - there is NO WAY for you to get a new password.
Comment has been collapsed.
LOl everything is possible well i'll expalin this one =)
When you ask for a password recovery & you agree that we'll change your password & send it to your email then
Comment has been collapsed.
and asks the app to change your old pw
ROFL. That's hilarious. Please, never write applications again. Or at least until you'll learn some basics about security.
Comment has been collapsed.
I told you, I'm a programmer. And if information in your facebook is correct - I'm working as a programmer longer than you exist.
Comment has been collapsed.
Okay thanks =),someday u'll wish u never said that, when people are mean to you
Comment has been collapsed.
1.) Have you penetration tested the server you are currently hosting the server-side code for gamekeyapp.com? If not, I'd recommend you immediately take that server offline.
2.) Does your app automatically update itself when there is a new version?
Comment has been collapsed.
1) secured no need to worry
2) it won't automatically update it self, it will show you a notification that there is an update, & u must update it.
Comment has been collapsed.
Comment has been collapsed.
I was just trying to have a little joke, but it did come off as a bit douchey, sorry.
Look, you may have the best intentions here in sharing your software, but you've got to realize how it looks from an outside perspective (really sketchy). As a developer you've got to be open to criticism, and there are some very valid ones here. Even if it's not outright malicious, the whole remote username system is unnecessary and insecure by design. And, as others have noted there are already better solutions for local key management such as Excel or Keepass.
If your intentions are good though, I hope this won't discourage you from creating more software in the future, but you should take some notes in dealing with criticism in a more professional manner.
Comment has been collapsed.
It's Okay thanks for saying that =) ,
Yeah, i can't agree more i already learned a lott, but i really didn't like people saying they used it and their keys got stolen, & they didn't even download the app.
When users see that they won't wait & judge for their selves , cz the answer is no clearly,
Am Open for any suggestions for any features that people can propose, i did my best adding some features that i found usefull on my side & some friends's.. the app is made to make their trading easier
Comment has been collapsed.
If this is a scam - its a sad attempt at that. He even has his facebook profile link in his profile description.
If its not a scam - its as sad if not sadder. Completely useless app, horrible grammar, rather sad youtube video thats hardly a tutorial or ad, arguments that should have been better kept to oneself
Comment has been collapsed.
Just stating the facts and how I see it
I suppose you can create what apps you want and share them. But dont forget that certain level of presentation has to be made for it to be believable. You represent your app here with horrible grammar (what do you expect the opinion of others to be about the app itself?). Then you boldly claim that your server will never be switched off and people wont be locked out of their accounts - any proof to that ? Everything just screams "unreliable" and/or "scam"
And sorry, but video with text in notepad is the last thing i would suggest using for anything ever.
Comment has been collapsed.
Comment has been collapsed.
Comment has been collapsed.
(only username, & email are sent to the server)
and I'm lost now
if you forgot your password ,we'll provide a new one for you, all u have to do is click "forgot password" on the login screen,we'll receive your email, and * Your username, and then we'll send a new password to your email.(u can change it later
Comment has been collapsed.
When you ask for a password recovery & you agree that we'll change your password & send it to your email then
Comment has been collapsed.
More important question is - why this password even needed then?
For example, if I forget my password to KeePass - all my passwords are lost, because they are encrypted. Because that's the idea of encryption - if you don't have a password - you can't decode data, no matter what. If someone stoles my KeePass database - I don't care! All passwords in the DB are safe, because there is no chance they will decode it without my masterpass (unless they have quantum computers, lol). Guess what happens if some criminals stole the DB with the keys from the app in this topic? They can just "ask the app to change your old pw to this new one". So password protects nothing in this case. And if it does not protect shit, why is it even there? To annoy user?
UPD. And funniest thing is that Microsoft Excel has an option to encrypt file with password, so it's actually safer to use it.
Comment has been collapsed.
Something from above comments:
password is stored in plain text
https://github.com/TheKiLLerDz/GameKey/blob/master/Login.js#L99
Yeah... 0 salt in the password screams secure as f....
Comment has been collapsed.
Google Excel Sheet is better and more useful then your App. Get over it.
If this is not a SCAM it is just a useless App.
Edit: And anyone can see my comment on Youtube and you said you deleted it and reported it but Youtube did not find anything wrong in my comment and it is still under your video. Anyone can check my comment vs your "screenshot" :) I also love how you asked your friend to like the video to promote this SCAM :)
Comment has been collapsed.
It's not about how password is stored... Because for encryption password should not be stored at all. In this case password protects nothing, so it does not matters if it's stored or not.
Comment has been collapsed.
OK, WTF is this comment??
What does religion, Allah or Muhammed have to do with any of that???
And what is this bunch of lies??? Comments like this are not ok even if it's just a joke
Is it because he is Arab?? that's racist
Enjoy being on the blacklist until you be respectful and apologize
Comment has been collapsed.
Ah I see. He deleted it in the end.
I wrote a funny commercial saying it is the best App for year 2020 to steal keys from people.
First he pinned it. Later he lied saying he reported it and deleted it. Now he post this "screenshot" and now he deleted my original comment so he can claim that his "screenshot" is true not fake.
Comment has been collapsed.
dude give me a break, u such a lier, i never highlighted that comment maybee it highlighted it self idk
i have reported & deleted the comment the moment i saw it, it's after 8-10min u have posted it
Also as i said if you can't stop lying i'll make a screen record that shows your clearly comment & post it somewhere
Comment has been collapsed.
funny? you are full of racism which is pathetic. you raged on him for beeing arabic if i read it right.
go vote for PIS and suffer
Comment has been collapsed.
You can believe what you want after reading the whole discussion.
I only rage because I was working for 2 years in personal data security field and that App looks like scam.
I don't vote for PiS. I don't like PiS.
But right now it looks like they did more for this country and its people than PO did in 10 years.
Comment has been collapsed.
first off, i believe what i read that you wrote about him beeing an arab.
you dont know shit about security according to your replies, all you did was accusing him without ANY proof. did you even check the source code? guess not, otherwise you wouldnt have left such stupid comments. your proof is based on rage and nonunderstanding a single shit of coding.
also about PIS... it shows me that you have no ffin clue what they are doing and what they are about to do.
Comment has been collapsed.
Well if you need any proof and people checking source code look for comments from people like: mercury529 and Ryzhehvost.
EDIT: And about PiS I know what they are doing and I know that it can be bad in the future for the people but now people get higher salary thanks to them, also people love them for 500+, still PO lost again because they didn't propose anything to people and said only that PiSa is bad and they are good so vote for us because we are good guys others are bad but it did not sell. I think PiS and PO are both 2 sides of the same coin made from shit. But still PiS knows how to play the political game and gain people support and votes.
Comment has been collapsed.
okay well actually i thought not to reply.
you mention other people complaining about his work. there is no proof at all that his addon is harmful in ANY way... if you cant read his code, please stop replying....
Comment has been collapsed.
I couldn't find his comment so I assumed that YouTube deleted it and the OP snap it before that.
If the screenshot is edited that's a new discussion to have
Comment has been collapsed.
why would i edit the screenshot ?
i reported & deleetd his comment, why would i keep it there ?
also i have a youtube email that validates this comment ++
so is he even denying this ?
Comment has been collapsed.
You said you reported and deleted it yesterday while you did not report it or deleted it yesterday only pinned it as a top comment :D
And if you would report it I would get notification from youtube about the report. And just like on FB if you write something that breaks the rules on YT you get 24h bans or more just like on FB.
An hour ago I still saw my comment but now I see you deleted it. Oh well :)
It was fun while it lasted to be your TOP comment pinned by YOU an author of the video - I guess you did translate the commercial I wrote in the comment about your App and after understanding what it was saying you deleted it :D
Comment has been collapsed.
Oh just a small note. A salt isn't particularly necessary if you're only storing a single hashed password as would be the case in an application like this (assuming it was properly implemented). The complexity of cracking a single hashed password is approximately the same whether it's salted or not. The salt is useful for increasing the complexity of cracking multiple passwords.
Comment has been collapsed.
No prob! I find the topic really interesting.
Just to clarify a bit, a salt of a single password is technically useful for preventing the use of rainbow tables. But if the password is sufficiently short/non-complex to appear in a rainbow table, brute-forcing that single password isn't going to be an issue anyway.
Comment has been collapsed.
A rainbow table is a giant pre-generated table that maps hashes to passwords. As an example, a rainbow table might contain a SHA256 hash of every single password that has 7 character or less containing only letters and numbers. If you hash your password with SHA256 and don't salt it, that means you can almost instantly find whether a user's password is one of those passwords the rainbow table covers. Make sense?
But the size of the tables grows exponentially when you increase a password length by 1 character. And it gets bigger still if you allow more characters in passwords. Salts effectively increase both the length and complexity of passwords, so they can render rainbow tables useless.
So by not salting a single password, you open yourself up to the use of rainbow tables. But because rainbow tables typically only cover relatively short and non-complex passwords, if your password would appear in that rainbow table, it's not going to take that long to just brute-force it even if you do salt it. So short passwords are never practically going to be better than long ones (even if I could think of some rare scenarios where they could theoretically offer an advantage).
Comment has been collapsed.
No problem. Happy to spread a little security knowledge.
Comment has been collapsed.
Alright, let me be honest with you guys here:
As a school project, or a resume demo that you understand Git, node.js, Electron, etc., this isn't a bad program. Interface design isn't really great, but as a programmer who failed just about every art class he ever took, I can't fault you for it.
As a key management system, though, it doesn't really have much value. As a developer, your job is to figure out what the client wants, and to reconcile that with what the client thinks they want. In this case, you really could've benefited by asking what potential users were looking for during the development process. As many others have noted, this app jumps through a lot of hoops to end up with something that in many cases isn't as useful as a simple spreadsheet.
The largest potential flaw is the account system. Yes, it appears to be local-only, but what operating system doesn't have local accounts in the first place? By forcing the user to create an account, using an internet-based identifier such as an email address, you're giving the impression that their data is being sent somewhere remote, even if that's not actually the case. For users who just want a way to keep their keys stored safely, the idea that someone else might be looking at them is a huge red flag. Again, it's something that works to demonstrate that you know the idea behind the system, but largely something that doesn't need to be in the release build.
Your release strategy is also a bit worrying. It's great that the source code for your app is available on GitHub, but that only makes it more suspicious when you chose to host release builds on something like MediaFire rather than using GitHub's release system. Further, there's nothing to identify which commit your 'v1.1' release is tied to, as there's no flagging or numbering on the GitHub page. The fact that you're releasing packed builds with binaries when your readme only shows users how to run the raw Node package only exacerbates concerns that you've slipped an extra bit of unsavory code into the prebuilt app, as it then becomes much more difficult to check against the source.
Overall, there's a promising demo here, even if it's not necessarily something most users will find a use for. Hopefully you can look past the scorn here and take away some lessons for future versions or other projects.
Comment has been collapsed.
Well First thanks for you opinion really appreciate it =)
Comment has been collapsed.
1,248 Comments - Last post 11 minutes ago by logorkill
158 Comments - Last post 27 minutes ago by DeliberateTaco
395 Comments - Last post 1 hour ago by wigglenose
39 Comments - Last post 2 hours ago by Foxhack
284 Comments - Last post 2 hours ago by Wok
8 Comments - Last post 6 hours ago by TheLimeyDragon
82 Comments - Last post 11 hours ago by GarlicToast
794 Comments - Last post 15 seconds ago by DrTenma
7 Comments - Last post 7 minutes ago by RiderOfPhoenix
117 Comments - Last post 20 minutes ago by Mikurden
656 Comments - Last post 22 minutes ago by PastelLicuado
169 Comments - Last post 23 minutes ago by Mikurden
31 Comments - Last post 35 minutes ago by slaveofwant
4 Comments - Last post 36 minutes ago by adam1224
GameKey v.2.0
GameKey offers easy access and management also a clear and simple data storage for your Keys, that will allow a wide trading capacity and a better handling of the deals furthermore a professional trading portal that will shape a relieve from the anxious process. Since none of the data will be saved on the web the privacy and safety of the user are beyond question.
Watch App Tutorial (PS:This Tuto is for the old version).
Check GitHub Wiki Page
Download From our Website Or from GitHub Release Page
This App was developed by me & my teammate
Source code on GitHub
GameKey is an application that let you store your keys on your pc & share it with clouds if you wish accessing it from other PC's.
Your keys are safe we won't save your data on our servers, The data is stored on your PC with a path u can change, with your account credentials access.
You Data is being encrypted so no one can decrypt this without your login credentials.
With GameKey u can easily know how many keys u have for a specific/ all game(s) u have, u can check ur stats etc.
You can search for your games more easily (platform, id, name.. etc)
there are many more features on the app, check them out.
IF you have any suggestion it's welcomed =)
Thanks for some users out here that made v2.0 possible, with your suggestions u made this.. =)
Comment has been collapsed.