Twine Version: 2.3.9
Story Format: SugarCube 2.33.2
Is there anyway to minimalize or prevent someone to hack into our games? I mean to prevent someone to see our source code so he/she wouldn’t easily knew the vault password or some secrets within our games and maybe do something nasty with it? Lol
It’s not really possible.
The best you can do is make it a tiny bit trickier to read and/or require editing the code and/or know to do some specific command line codes.
An example of the first one would be my “Simple Password Hiding” hashing tool, which turns a password into a number. That way the password doesn’t exist in the code which verifies the password input.
You might also consider minifying your JavaScript, since it not only makes it harder to read, but it also decreases the file size. Here are some example sites.
Honestly, I wouldn’t worry about it too much, though. If people want the game spoiled for them, then let 'em.
Hope that helps! 
I keep meaning to write some rude things in the beginning of my source code, so that anyone who peeks will be in for it!!!
It “appears” to work with small files. Might choke big time on more substantial work?
I just tested it with the demo chapbook example:
I guess a more substantial Twine Story would be needed to see how “robust” or “useful” it really is…
– 8<—
EDIT:
LOL!
just realised that unescape() from the console gives you back the original javascript!
useless! but funny… 
Yeah. That’s the price we must pay for prevent anyone to peek our code LOL.
Maybe there’s more cheap sollutions for this?
Whats more, this encryption might broken some advanced code in our games, damn.
I mostly have played games decades after they came out. For such games, it is wonderful to see how they were made and explore their code by decompiling or otherwise. Disabling it now might affect future players in a bad way, and how does it help you now?
What’s the benefit to the player? Will there be many players who want to look at the code, found out you hid it, and think, ‘Ah, my enjoyment of this game increased, my esteem for the author is higher, I am glad I cannot access this code?’
If it doesn’t benefit the player, then who does it benefit? The author? It might keep you from having people copy your code, but I don’t think I’ve ever seen a Twine game that was worth playing where the author wanted to make sure others couldn’t copy them. In fact, most very successful twine authors seem to go out of their way to help others (Anna Anthropy, Porpentine, Grimoirtua and Astrid Dalmady are people I know of who have tried to help others make games like theirs).
you make the point here, community will grow faster if there’s no secrecy and all goes public, everyone can have it and do what they want.
i’ll do this way, but surely hell i’ll encrypted my vault password for sure. dont dare to play tricks on my password period. LOL
Thanks for considering my opinion, I appreciate it!
A sneaky (& experienced) individual (like myself) would just use a TWEE decompiler to extract the project’s source code, which would then allow them to alter the code so that access to the vault was automatically allowed. 
In short, both the end-user’s web-browser and the Story Format’s engine needs to understand the contents of the Story HTML file. And that means that it is fairly trivial for someone to bypass what ever means you use to ‘secure’ the story HTML file or its content.
I’m thinking about the real question behind this - since this is something I’ve struggled with myself – cause it doesn’t seem like you’re against the idea of seeing your source code but more you don’t want people to cheat to see the puzzle solutions, particularly for some of the super-secret stuff hidden in plain sight. I am such a proponent of super-secret stuff that’s hidden in plain sight myself (my comp game this year is all about super-secret stuff hidden in plain sight!) And I’ve had people who’ve found my super-secret stuff by looking at the source code, and it is so crushing. (When I was a kid I was playing Treasure Hunt with some friends and they were in my room while I went through the house hiding the treasure and a series of intricate clues. While setting it up, I told my mother where I’d hidden the treasure, and when I opened my door, my friends immediately made a beeline for the hiding spot, skipping all of my clues, because they’d overheard, and that was my first crushing disappointment as a game designer.) I have learned to grit my teeth and just //smile// and say, wow, that still counts as a win even though it’s not an honest win because who am I to let someone not metagame? I cheat in games all the time. I look up walkthroughs and feel absolutely no guilt about it.
I guess when I’m feeling pretentious I look on my stuff as a weird form of communication between me and the player, which is one of IF’s real strengths. So, like any kind of communication, there’s a lot of opportunities for misinterpretation. The secret in the box really doesn’t have any value in and of itself – usually my secrets are underwhelming because secrets usually are underwhelming. (Remember what happened to Twin Peaks once they revealed who killed Laura Palmer.) The secret isn’t the point. The fact that it’s in a box is the point. The fact that that box is locked by puzzles, each with their own things to say, is the point. The fact that the box is placed on a shelf is the point. The other things on the shelf with the box are the point. Someone comes in, smashes up everything on the shelf with a hammer, sifts through the ruins, and finds the secret has just found a worthless drop of water. And that sucks – but that’s the thing with communication, you can’t get 'em all. The right people – the ones who understand what you’re really trying to do – will appreciate the knickknacks.
Anyway, this is the zen perspective I am forcing myself to have, especially because I bashed against this same wall and gave up for the same basic reasons Honestly, my code is a goddamn mess and I’m surprised the thing runs at all; it’s super embarrassing!
i think i should change the title to “how to protect my vault password as only TME can bypass it !!”
hmm yes that’s should be good
Electron apps don’t obscure the javascript code – it’s all right there in the app package.
Also, with Electron, you’ve changed from a lightweight web page to a 50-megabyte downloadable app. This makes sense in some contexts (like putting your game up on Steam), but if your audience is the general Twine audience, it will feel really strange.
My advice is to worry about finishing your game, not whether players will “play it wrong”.
If you’re encrypting it to prevent others from stealing your code, then I understand. Don’t encrypt it to prevent players from cheating. Let them cheat.
This is a lot like the argument against modding PC games or using GameShark/Game Genie cheat devices on consoles. Once the player purchases/downloads the game, the game is the player’s property now, not yours. Why tell them how to use their property? It’d be like Toyota insisting that Corolla owners don’t lower their car or put a spoiler on it because it’s supposed to be a responsible family car.
I’m sure you’re proud of your puzzle, but are you proud enough to prevent players from playing further just to keep them honest? I seriously doubt people will cheat. But you’re basically telling them that your ingenuity is more important than their enjoyment of the game, and that they don’t deserve to play further if they don’t finish this puzzle. But who loses out more in this stance? The player that has a zillion other games to play and only wasted a few minutes on this one, or the developer that went out of their way to ensure that players won’t see the rest of the game that they put tens to hundreds of hours developing?
Anyway, I just woke up so that was kind of rambly. Let people modify their cars, root their phones, cheat and mod their games, and do whatever they want with their property. Thank you. The end.
No.
I understand what you are behind. But most players just wants to play and rest of them know how to hack, which you cant prevent.
But instead of adding your secret passwords to the source file, you could use MD5 hash.
Basicly, you create a MD5 hash from the vault password. You can do this nearly with any common programming language and add the result as part of your sourcecode. From this hash, its is allmost impossible to know, what the original password was. Then you add js-function to game what calculates hash value of what player has quessed it to be. If these two hashes match, player has quessed the vault password correctly.
You could also try using rot26. I’ve heard good things. http://rot26.org/
(This is a joke. :P)
I’m with Mathbrush and others on this. What is the point? If you’re a good author, the password will be clued in your game in a way that’s enjoyable for players to work out by playing. If a player really IS stuck (and has exhausted all your clues, hint systems, etc., which you made because you are a good author who wants to help players enjoy themselves) maybe source-diving is the only way they can see the second half of your game. Why would you want to stop that? It’d be like giving someone a book with the second half of the pages glued together.
ETA: Note that at this point, source-diving is a compliment. If a game gets me stuck, I’m probably more inclined to give up and move on to one of the other several million multiples of my lifetime’s worth of free games out there. If I bother to sift through the code, I must be really engaged.
If you still want to prevent that, a surefire method is to make sure your game isn’t very good
A lot of words have been written here, but I don’t think you’ve said much about why you’re trying to hide your vault password. Is it just to prevent cheating? Why do you want to prevent cheating?
I presume you meant “TIME” there. But presumably you don’t just want time to solve it… Don’t you also have some puzzle you want the player to solve? May I suggest that your goal is to make the player solve a puzzle to get the password?
Well, viewing source and understanding it is also solving a puzzle. Most players don’t have the expertise to solve the puzzle that way. Is it OK if some players solve that puzzle instead?
If you make your code a little harder to understand, (or a lot harder,) cheating can be an interesting puzzle in its own right. Is that good? (Is that good enough?)
People in this thread have pointed out that you can’t make it impossible to cheat, which is true. (We can’t even build a web site where it’s “impossible” to steal passwords!)
But it is possible to make it harder to cheat than it is to solve the real puzzle. Much depends on how skilled the player is at solving the real puzzle, as opposed to how skilled the player is at cheating, of course.
If your real puzzle is actually very easy (there’s a vault, with a sticky note with the password on it right next to the combination lock), it may already be the case that solving the “real” puzzle is easier than cheating.
I assumed they were referring to TheMadExile, the creator of sugarcube, who is usually referred to as TME for short.