diff --git a/_posts/2024-03-15-password-reset-vulnerability.md b/_posts/2024-03-15-password-reset-vulnerability.md
index 9b2280f..c111a60 100644
--- a/_posts/2024-03-15-password-reset-vulnerability.md
+++ b/_posts/2024-03-15-password-reset-vulnerability.md
@@ -19,7 +19,7 @@ On Dec 22nd, 2023, we received the report about multi-factor authentication (MFA
 
 In the screen recording, the reporter showed the following:
 
-1. Use a tool to store the full response from a valid password reset on an attacker controller user without MFA.
+1. Use a tool to store the full response from a valid password reset on an attacker-controlled user without MFA.
 2. Use the same tool to man-in-the-middle (MITM) the request by the victim (an MFA enabled user).
 3. Swap the saved response in place of the MFA challenge response for the victim before it is returned.
 4. Change every `user_id` in the page to the victim’s `user_id` (mostly to places that I could tell did not matter, which added skepticism).
@@ -34,7 +34,7 @@ I can come up with a lot of excuses for why I couldn’t possibly have seen this
 
 ## Investigation
 
-Luckily the reporter was very responsive to my requests and I was open to being proven wrong. The report was filed at 5:30am Dec 22nd and by 7:30pm the same day we had communicated back and forth for hours. By the 3rd screen recording and after a discussion with Samuel Giddins, our AWS sponsored Software Engineer in Residence, we finally arrived at a proof of the vulnerability. The report had found a real issue.
+Luckily the reporter was very responsive to my requests and I was open to being proven wrong. The report was filed at 5:30am Dec 22nd and by 7:30pm the same day we had communicated back and forth for hours. By the 3rd screen recording and after a discussion with [Samuel Giddins](https://github.com/segiddins), our AWS sponsored Software Engineer in Residence, we finally arrived at a proof of the vulnerability. The report had found a real issue.
 
 The vulnerability worked like this: the password reset form (the `edit` action in our rails app) was well protected behind MFA and an email token. You could not render the form without verifying your MFA credentials. However, the submit action on the form (the `update` action in our rails app) only checked the email token and did not care if you had previously submitted a valid MFA. Oops. _All the seemingly pointless changes the hacker was doing were for the purpose of rendering the form so it could be submitted without having passed the MFA check._