This project aims to create a password generator using a physical device, specifically the M5StickC Plus. The key goal is to ensure that the device regenerates the same passwords whenever the same patterns and inputs are provided.
Unlike traditional password generators, where passwords might be hardcoded or stored directly on the device, this solution provides a dynamic and secure way to generate passwords based on user-defined inputs consistently.
This approach offers a level of security and convenience for users who require unique, secure passwords for different applications but want to avoid storing sensitive data on physical or cloud-based platforms. However, it also has its downsides.
Imagine frequently accessing multiple online accounts requiringsolid and unique passwords. Instead of using a password manager or storing these passwords somewhere, you have your M5StickC Plus device, a physical password generator, ready to help.
Each time you need to log into a service, for example, your Google account, you know that the password for Google is associated with Bank A and a 4-digit PIN of 1200
, and you prefer a password length of 12 characters. You turn on your M5StickC Plus, select Bank A, enter the PIN 1200
, and specify the password length as 12. The device instantly generates a secure, unique password, which it sends wirelessly to your laptop via Bluetooth as if it were being typed on a keyboard.
Because the password is generated deterministically using the Device ID, SHA256 hashing, and your specific inputs, the same password will be generated each time you enter this pattern. This ensures that you never have to store the password—it will always be the same as long as you input the correct combination of Bank, PIN, and password length. If you lose the device, an attacker would still need both your M5StickC Plus and knowledge of your specific input patterns (Bank, PIN, and length) to regenerate your passwords.
Risks and Security ConsiderationsThis project uses open-source technologies and is based on Arduino code running on the M5StickC Plus, a device that lacks built-in memory encryption or advanced security protections. As such, there are some important considerations regarding the security of the device and the code.
Security Risks:- Open-source Nature: Since the project is open-source, the code is available to anyone. This means that the device ID and initial PIN are potentially visible in the code. Although the user can change these, it's essential to recognize that anyone with access to the source code can see how the system works, which may present security risks in the wrong hands.
- No Encrypted Memory on Device: The M5StickC Plus does not have hardware-encrypted storage. Any sensitive information stored or processed by the device, such as the device ID or runtime variables, is vulnerable if the device is physically compromised. No secure enclave or encrypted memory is available to store information securely on the device itself.
- Hardcoded Values: While the device ID and initial PIN are hardcoded into the Arduino code, the user can modify them before flashing the device. However, it’s essential to understand that these values are visible in the source code, which is not the most secure method if the code is publicly shared.
Despite the risks above, the project provides a more efficient way to generate and manage passwords with some notable security features:
Password Generation by Device ID and SHA256 Hash: The passwords are not hardcoded. Instead, they are dynamically generated through a combination of the device ID, a SHA256 hash, and a user-defined PIN and bank. This ensures that:
The same combination of inputs will always generate the same password, making it easy for users to remember input patterns (like A1200/12
) rather than actual passwords.
For strong password creation, passwords must be consistently unique and can include uppercase, lowercase, numbers, and special characters.
No Account Data Stored on the Device: One of the biggest advantages of this project is that no account data or sensitive information (such as service names or account usernames) is stored on the device.
For example, if a user knows that their Google account uses the pattern A1200/12
(Bank A, PIN 1200, 12 characters), they only need to remember this pattern. The actual password is regenerated on-demand by the device using the known inputs.
- Even if the device is physically compromised, the attacker would not know which accounts are associated with which PINs and banks unless they have access to additional external information (such as the user’s records).
- Separation of Data and Accounts: Because there is no clear connection between the generated passwords and specific accounts (i.e., which Bank/PIN combination belongs to which account), it provides an extra layer of security. If the device is compromised, attackers cannot easily deduce which password belongs to which account without additional information from the user.
While this project is not suited for high-security use cases that require encrypted hardware or secure storage, it offers a practical and secure method for generating dynamic passwords. Users who take care to manage the physical security of the device and customize the code with unique device IDs and PINs can benefit from the convenience of consistent password generation without relying on insecure storage solutions.
Comments