Hey all,
This thread is documenting my struggles with @Atomic_Charge's GET CRACKIN' challenge.
As I mentioned in my post there, I'm going to be creating a password manager because I'm frustrated with the state of current password managers. If they were easier, I'm sure more people would use them. That's my goal here. I'm going to build something that's so seamlessly intergrated with major browsers and other systems that it's almost easier for people to use it.
Currently the project is not complete and not near working prototype stage.
If anyone has a working knowledge of data security in this context, let me know. I'm in need of someone who may know a few things about keeping this secure.
Day 1: framing the GUI and building the data store
I've never really touched GTK+ before, so this is a very new area for me. I'm sitting here with coders block, so I've decided to get lunch. I'm going to put the github link up after I get some more code in the repo, but for now, I feel more comfortable keeping it secret.
Currently I'm thinking I'll use a custom class to handle storing the account data, preferences and other information that will be held in a database. I've decided on the cryptography.fernet module to encrypt the entire store as AES_CBC.
I'm thinking about using secondary encryption on the passwords so that a memory cloning attack can make it more difficult to get the data. that would require a bit more work though. In order to do that, I'd need to make sure that we store a secondary key in the data store and use that to decrypt the password from an account. That would also require making sure we pass by reference so we can securely wipe the memory address that stores the data. Pass by refernce at a cursory glance, looks overly complex compared to C. I guess it's time to get started on the data store decide how best to implement the Fernet encryption.
I've got the data store partially framed. I'm going to be using custom-written classes to handle storing the data, as opposed to something that's available. Hopefully this will allow easier fuzzy searching of the data. I had a not so good day writing code, so I decided to go bowling with friends around 16:30. Hopefully tomorrow will be more productive. I have to meet a client at 12:00, but when that's through, I'll be writing code for the rest of the day. I've got my fresh air for the week, so hopefully, I'll be set to work tomorrow. I've also cycled in air from outdoors through my work room a couple times today.
Day 2: Finishing the data store and frustrating encryption
So, where to begin. I'm not quite finished today, as there are a few things I'd like to add in to the data store before I call it done, but I'm pretty confident that the storage and retrieval part of the data store is complete and stable. I guess time will tell for sure.
I've got encryption working as well. I've spent a good 4 hours working on this and it's bothering me that I didn't know enough to get this stupid stuff working quickly. Essentially, I was struggling with getting strings converted to binary format. This is accomplished by calling str.encode('utf-8') which will return a format that the cryptography module will accept.
The in-memory database, while most data is decrypted, keeps the password encrypted until it's needed. This will add another layer of security, by reducing the chances of a password being stored in plaintext in memory. I'm not sure how well this will work in practice, since the attacker may have the password, salt and number of iterations the KDF module uses. Even though, that can make getting into a database easy, if an attacker can pull data out of your system memory, I'd argue that you've already lost. This is why I always recommend shutting down instead of going into sleep mode or hibernating.
I've also got the storage and retrieval of the database working. Essentially, what a .kmdb file will look something like this:
{
'version': 1, #database version, just in case we run into compatibility issues, we can run upgrade methods against the database.
'secure': 'AES encrypted cyphertext, although, it may be early to call this data secure.....',
'config': {'iterations': 1000000, #default iterations
'key_type' : 'SHA256', #algorithm to hash the password, that gives the key for the fernet module to encrypt data.
'salt' : 'b'\\\xe8\xc5\x8ei\xebd\xe6\xba\xbcM<\xdc7[\xa7' #example salt for key.
}
}So essentially, we're going to be having three items that are not securely stored. key type, iterations of sha256 and salt. Again, I'm not too familiar with cryptography, so I'm not sure if we are able to encrypt that data. If someone can chime in and tell me what requirements there are, I'd be grateful.
I'm doing a few tests currently to double-check the sanity of the storage method, but once it's done, we should have smooth sailing and I can move on to the (arguably) more frustrating aspects, GUI.
Day 3: Files and Groups
Today I spent quite a while learning about how GTK popup windows and Entry classes work. I'm happy to say I'm getting very close to a functional prototype. The thing that's holding me back mostly is that there are a few aspects of the program that don't quite feel right. Adding and removing account groups isn't all that smooth right now, but I may have that sorted shortly. I've not even begun to work on editing account groups, but that can't be too difficult.
I haven't got the front-end to work with actual Accounts yet, short of showing a simple ListBox of them. That's okay though, I'd have to say it's been only about 15-20 hours and 1127 lines, so if I consider that, it's not bad. I'd say I'm going to have another 20 or so hours to get a stable build. I'm not sure what we should call stable, but I'll definitely call it 1.0.
I'm also going to eventually build a Firefox and Chrome plugin to interface with the program. I'm still hashing out (pun intended) how I'm going to securely implement this, but my first thoughts are to add a section in the "secure" part of the database where we can store private/public keys that the browser plugins can use to communicate to a Unix socket and transfer data as needed to and from keymaster's database. These key pairs will be automatically configured, but the user will need to manually verify each plugin the first time it connects, to prevent malicious code from attempting to connect to the API.
I'm not sure how people feel about storing sensitive data in python, but I'm definitely interested in finding out, so please let me know what you're all thinking on this.
I'm starting to cut it close to the deadline for Get Crackin' but I'm not letting up. I've been a bit busy this week, and next week I'm going to probably be working nearly 70 hours, which doesn't bode well for the deadline, but I'll definitely be submitting the project regardless. I also plan to maintain and iterate on the project for the foreseeable future. So unless I kill myself on my bike, this project will stay alive.
I don't expect browser plugins to make it into this month's challenge, as I've never built one before, but I plan on using the next challenge to either iterate on this project or build something else.
Alright, long update. This was a productive day.
Day 4: Account details and more
Today I spent a good amount of time getting the account details working. It's obviously not very pretty yet, as can be seen from this post, but I'm not a UI engineer. If anyone has input, please do tell me. I keep thinking something isn't quite right on the details pane (right side of the window). It's just not doin' it for me on the visual aspect.
I also made an attempt at building a password generator, but that isn't working quite like I wanted it to, so I've held off on implementing it in front-end. It's definitely in the backend, but you'll see why it won't do if you look at the code.
I've added a lot of code to widgets.py, as I'm starting to code more modularly. It's really helping me speed things along, although, it's not 100% modular yet. I'll add that to my todo list as "pre 1.0". I also realized that the password binary conversion isn't proper, so I'll have to change that up asap. I'm using a method that doesn't quite cover all cases when I should just use str.encode('utf-8'). That's probably what I'm working on tomorrow.
This project has started to be less about the whole Get Crackin' challenge an more about keeping my mind sharp. Regardless of the place I am in in life, I tend to get depressed. This has given me a good distraction from that. I suppose when you're busy, you don't have time to be depressed.
I'm still having problems with FileChooserDialog, so if anyone has any suggestions, that would be awesome.
This update is brought to you by Tostitos and Ballast Point.
Day 5: Account CRUD, Group Icons, Finalizing Files
Today was a hell of a day. I'm extremely satisfied with my progress. I'm not quite through with what I'm doing, but I've got responsibilities that I've been putting off, so I may be calling it quits for the day.
Today I got account CRUD working. You can now create, edit and delete accounts from the account details pane. That took a while, and there is still more to do with the account details aspect of it, there are a few things that just don't want to render at all. (I'm looking at you, Gtk.TextView) Anyways, I'm at the point where I'm happy with my program, minus a few little things, that over the next week, I should be able to iron out.
Addressing files; yesterday I mentioned I was having issues with FileChooserDialog. I have successfully made it my bitch and achieved glory by getting it to operate in a manner that I'm happy with. At this point, we have a system for loading databases, saving databases and creating a new database. I can't imagine we'd need much more, except maybe a save as...
I've created a dialog for configuring a new database. I don't currently have away to edit the settings, but that is one of the small things that just needs to be fixed. For now, it allows you to enter a password, (twice, with correctness verification), set the number of rotations on the key we do and enable markdown support for notes, which is 100% not supported currently, and probably won't make it into V1.0, so I may remove that checkbox.
In addition to the account details, I'm doing a little work on the group add dialog. I am going through the gtk icon browser as I type this, looking for good icons to include in the default set of icons for the system. The idea is you click the plus icon to add a group, you set a group name, and you choose an icon. If you don't choose an icon, you'll be using the (as of now) default system-lock-screen-symbolic icon, to help prevent crashing the beautiful program that is.
I still need to work on the group-rename, and group-remove. I want to make sure that if there are accounts within the group, it warns you that you will lose all the accounts within that group upon removal. Ideally, we'd have a configuration where it just removes it and gives the option to "undo" the action, but I'm just trying to get the system working, then I'll work on making everything nice.
I think it's safe to say, that short of a few (essential) features, I have a working prototype, so at any time, I'm able to submit it as "complete" but that would only discourage me from working on it, so I want to get it further along.
Now to be responsible.
Day 6ish: Preparing for end of Get Crackin'
Today was frustrating. I spent way longer that I should have trying to figure out how to get a mysterymeat menu, (the icon between search and your user icon on the forum) working in the method I wanted, and it's still not perfect. :/ I just clearly don't know GTK+ well enough. I'm at the point where the system is almost ready. I've got editable preferences that save, password generation, but no auto-type. That's the plan for tomorrow. Hopefully I won't have a migraine tomorrow. I'll be posting some images in a post below after posting this.
I'm having issues with parts of the account details pane, but I'm working on that currently. Ideally, I can pound out the issues there and I can call it finished.
I'd like to make a few additional modifications to certain features of the password field of the account details pane, but that may happen after I submit.
I think I'm nearly complete on the GTK side of the application. My next stages are to start building an API for a UNIX socket and start building browser plugins, which will be another first for me.
All in all, I've learned a hell of a lot about GTK and definitely like it better than web browsers for building a user interface. It's just so much more robust and nice. I mean, For every object I want, I extend the GTK class of the closest thing to what I'm building and make my modifications. There isn't really an equivalent to that in web development until you get into Angular and other frameworks. I guess I can add front-end development to my resume now...
Short update today. This update made late by Nvidia cards.
I'm not used to writing like this, so bear with me while I get in the habit of it. Also, much of this text is going to be written when I am too tired or distracted to work on the actual code, so I'll be in a less coherent state. You have been warned.
While I won't be able to update this daily, I plan on updating it regularly. Ideally, there will be three or four updates per week.
