Giter VIP home page Giter VIP logo

Comments (5)

foxxtrot avatar foxxtrot commented on May 30, 2024

And if a person has the ability to take a screenshot of the "hash colors" to get the hash, they probably have plenty of other choices related to taking your password.

from chroma-hash.

shadowhand avatar shadowhand commented on May 30, 2024

I agree, but a photograph, or someone making a screencast would be in the same boat. Your "hash" parameter with the latest version is a step in the right direction, but I think that using a random salt, or being able to specify true for the hash parameter to add a random salt would be a very good addition for security.

from chroma-hash.

mattt avatar mattt commented on May 30, 2024

Making the salt random each time would mean that the colors would be different every time. At that point, it's nothing more than eye candy, as the user won't be able to tell a correct input from an incorrect one.

If the hash were salted from a dynamic source, such as a server-issued cookie, then even a screenshot of the page and its source code would not be enough to break it.

from chroma-hash.

shadowhand avatar shadowhand commented on May 30, 2024

Making the salt random each time would mean that the colors would be different every time.

Yup, and I said that at the end of my original issue report. However, my personal feeling is that most people are not going to remember their 3 colors, but are going to be looking that the colors on both inputs match. This really only applies to a situation where you have a password and password confirm field, and I think it should be an optional feature (like {hash: true}).

from chroma-hash.

mattt avatar mattt commented on May 30, 2024

It is relatively simple to randomly salt the hash with something like {salt: Math.random()}

Adding a parameter for a random salt in this case would be somewhat redundant, in this case, and is not worth the added complexity. Also, having essentially random colors every time does not strike me as a particularly valuable use-case. The only advantage I can think of would be a sign-up flow for password confirmation / strength, in which case existing solutions are probably better. Unless the use case you're describing becomes prevalent, I wouldn't feel strongly inclined to add this option.

That said, you do illustrate a potential vulnerability in using the default options, which I hadn't fully considered.

from chroma-hash.

Related Issues (9)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.