This sprint we finished our prototype API and had it approved by Ampath. We also started working through the implementation details for our service as a group. Finally, we figured out how to repair our local versions of the app and get our group repository in synch with Ampath’s master branch so that we can implement our API over the next sprint. I learned how to coordinate with other teams to build an API, and how to implement password hashing and data encryption.
I think the biggest takeaway for me this sprint was how to coordinate with other teams on a project to write an API for them to use, and how to integrate details of their implementations into my team’s work. Because we’re providing a “background” service for the other teams, they can work for now assuming that our service will do what it’s supposed to. However, this means that we need to understand some details of their implementations so that we can provide them with what they need. Given the speed with which the semester is coming to a close, the encryption service may not be integrated into other services or components this year. However, we hope to have something that’s usable for Ampath or another group working on this project to take over in the future.
Our biggest job this sprint was to work on our service’s public API. We did this primarily through team work periods in class. This followed a roughly three-step process, which we repeated until we believed our API was in a state where we could send it to Ampath for approval. First, we spoke with another team to get a handle on their requirements for our service. Second, we wrote a set of function signatures that we believe filled those requirements. Third, we discussed implementation of those functions and what other private functions we might need to implement them, as well as which parts of the Crypto-JS API we want to use.
One of the biggest parts of this discussion was to figure out how we want to derive private keys and store hashes in order to provide the best compromise between security and usability. For password hashing, we decided to store a hash derived from the password with salt derived from the username and timestamp of the offline session creation. This will be stored with the username in-browser, by the offline login team’s code. For private key derivation and storage, we spoke with Ampath and agreed on temporary private key storage for the duration of a login session (the key will be generated from the password using a password-to-private-key function and stored in a file that is deleted on logout). While not optimally secure, this allows encryption/decryption of data without requiring password entry for each data operation.
We followed Jason Knowles’ intructions to rebuild our apps, and used git to update our team repo with Ampath’s latest changes. For next sprint, our job is to implement and test as much code as we can manage.
I think our team coordination could have been better this week. It felt like a lot of what we were doing didn’t engage the entire team, although I’m not sure how to manage that better. Not everyone was present for each work day for varying reasons, although we did keep in touch on Slack we could also probably have kept better notes to send to absent team members. I think dividing up labor will be easier next sprint since we have actual code to work on. We will have to make sure we keep our repositories synched, as we don’t have a ton of practice with that.