Bcrypt Puns

My thought is that even if the DB leaked and even if they got the salt by hacking into the server they would still have to deal with the md5 they wouldn't be able to decode it without knowing the original value is because first, they would have the guess the md5 hashed value that bcrypt generated then decode it with the salt.

What do you guys think? I hope that hacking won't be an issue though as my production environment will be locked down pretty well.

Given that the purpose of salting is to stop brute-forcing attacks, does an auto temp account suspension until password reset after say 3 failed attempts largely negate the benefit of salting? That is not to say that implementing salting is not to be discarded in such a scenario (the more security, the better). And if you have lockout after 3 fails, I would imagine a larger number of salt rounds would be more acceptable as only 3 attempts on the decryption can be attempted? 10 is the standard it seems, thinking about running with 13.

Thoughts?

• I am trying to build an user account system complete with signup/login etc for my webapp
• While storing passwords, I seem to have a couple of choices
  • bcrypt for native performance handled by express server
  • bcryptjs for pure js no dependencies approach again handled by express server
  • pgcrypto for handling password hashing completely in the database as this answer on stackoverflow mentions
• What is the difference between handling password hashing at the web server vs database server layer?
• Which one are you using and what do you recommend?

Hi friends !

I'm running into an error while trying to log in users.

It alway gives me 'ValueError: Invalid salt'. I tried things that i found on different forums and documentations, such as decoding the hashed password with .decode('utf8'), but always the same issue...

Here is my code:

The user class:

class User(db.Model, UserMixin):
    id = db.Column(db.Integer(), primary_key=True)
    username = db.Column(db.String(40), nullable=False)
    password = db.Column(db.String(), nullable=False)
    equipe = db.Column(db.Integer())
    niveau = db.Column(db.Integer())

The register form:

@ app.route('/admin/add_user', methods=['GET', 'POST'])
def add_user():
    if request.method == 'POST':
        username = request.form.get('username')
        password_base = request.form.get('password')
        pass_confirm = request.form.get('password_confirm')
        if password_base == pass_confirm:
            password = password_base
            pw_hashed = bcrypt.generate_password_hash(password).decode('utf8')

        else:
            flash('Passwords are not identical')
            return redirect('/admin/add_user')

        niveau = request.form.get('N')
        new_user = User(username=username, password=pw_hashed,
                        , niveau=niveau)
        try:
            db.session.add(new_user)
            db.session.commit()
            return redirect('/')
        except:
            print('ERREUR002: User could not be created. See the administrator')

    return App.render(render_template('add_user.html'))

And the login form:

@app.route('/login', methods=['GET', 'POST'])
def log():
    if request.method == 'POST':
        username = request.form.get('username')
        password = request.form.get('password')
        user = User.query.filter_by(username=username).first()
        user_pass = user.password
        checked = bcrypt.check_password_hash(password, user_pass)
        print(checked)

        if checked == True:
            login_user(user)
            return redirect('/')

        else:
            print('dont work buddy')
    return App.render(render_template('login.html'))

Thanks so much !!

I have been trying to figure this out for awhile and I don't understand why result is coming back false or why I am getting an unauthorized from postman. any ideas

const express = require('express');
const loginRouter = express.Router();
const {pool} = require('../config');
const bcrypt = require('bcrypt');
// login imports
const passport = require('passport');
const localStrategy = require('passport-local').Strategy;
const res = require('express/lib/response');
// const JwtStrategy = require('passport-jwt').Strategy;
// const ExtractJWT = require('passport-jwt').ExtractJwt;

passport.use('login',new localStrategy({
    usernameField: 'email',
    passwordField: 'password',
    passReqToCallback: true
},
function (req, email , password, done) {
    // console.log(password);
    // console.log(email);
    pool.query('SELECT * FROM users WHERE email = $1; ', [email], 
      function(err, data){
          // console.log(data.rows)
          // console.log('got here')
          if (err) {
           console.log(err)
           return done(null,false, {message:"There was a problem logging in"})
        } else {
          if (data.rowCount === 0) {
              return done(null, false, {message:"Incorrect Email or Password"});
          } 
          // console.log(password)
          // console.log(data.rows[0].password)
          bcrypt.compare(password , data.rows[0].password , function (err ,result){
            // console.log(password)
            // console.log(data.rows[0].password)
            console.log(result)
            if (err){
              console.log(err);
            }
            if(result!== true){
              
              return done(null, false, {message:"Incorrect Email or Password"});
            } else {
              return done(null, data.rows[0], {message:"Login Successful"})
            }
          })
        }
    }
    )  
  }
))

passport.serializeUser(function(user, done) {
  done(null, user);
});

passport.deserializeUser(function(user, done) {
  done(null, user);
});


loginRouter.post('/',
  passport.authenticate('login'),
  function(req, res) {
    // If this function gets called, authentication was successful.
    // `req.user` contains the authenticated user

Source - https://dropbox.tech/security/how-dropbox-securely-stores-your-passwords

So an implementation of this (ignoring await): -

import sha512 from 'crypto-js/sha512'
import aes from 'crypto-js/aes'
import bcrypt from 'bcryptjs'
const SECRET_KEY = 'whatever' <--- would not be hardcoded, this is just an example
// incoming user password
const userPassword = 'p@ssw0rd123'
// SHA245 hash the password
const SHA256HashedPassword = sha512(userPassword)
const bcryptHashedUserPassword = bcrypt.hash(SHA256HashedPassword, 10)
// AES hash the password
const AESHashedUserPassword = aes.encrypt(bcryptHashedUserPassword, SECRET_KEY).toString()

Does that look correct?

What are people's opinions on this as a method? Overkill? People tend to have very different views on peppering passwords. I can see an argument for and against. Although here it's not really being used as a typical pepper. It's only a pepper in the sense that it is a global (not user-specific) hash that is kept on the server. However, here it is not included as an addition (prefix/suffix) to the password string, rather an encryption key to further mangle the shadow password into something that is not even recognisable as a bcrypt shadow password.

Thoughts?

Hello,

When a user registers on my iOS app, I currently hash the password in Swift with Bcrypt (perhaps this is bad practice though and I should really send the plain text password over initially and hash with on my server? figured it was better to not send over a plaintext password but maybe I'm wrong), send the hashed result over to my SQL database, and store it.

Then, when the user tries to log in again, I want to compare the password they enter with the hashed password I have saved. However, for security reasons, you can't compare two hashed passwords in Bcrypt, so the only way to compare passwords is by comparing the plaintext password with the stored hashed password.

This means that I have to send a plaintext password from the iOS client over to my server, and compare it with the hashed password associated with the user in my SQL database. I'm a bit concerned about sending over a plaintext password though. Is the encryption provided by HTTPS secure enough to protect this information while it's in transit from the client to the server?

Thanks

edit: found this https://stackoverflow.com/questions/962187/plain-text-password-over-https so should be alright -- perhaps initially I should send over the plaintext password at sign up too? And hash it on the server, instead of on the client?

I'm following this flask tutorial, which is very old but still very good. The only thing is that I have to adapt a lot of stuff that is now deprecated. In this lesson Bcrypt is used, for which there haven't been any releases since September 2015. There is a fork with more recent releases, but it seems to be maintained by one person only.

My question is: should I use Bcrypt professionally, even though it hasn't been maintained in such a long time? Is there a more up-to-date alternative? Or is hashing from 2015 perfect as it is and there's no need to maintain it (i.e.: Bcrypt does one thing only (hashing), and it does it well)?

So I'm currently doing a tryhackme room (Daily Bugle) and one of the challenges is to crack this hash: $2y$10$0veO/JSFh4389Lluc4Xya.dfy2MF.bZhz0jVMw.V.d3p12kBtZutm

I looked up the format and it's bcrypt, so naturally I enter

"John hashfile --wordlist /usr/share/wordlists/rockyou.txt --format=bcrypt"

And I get back nothing. I looked at the writeups, and it SHOULD have returned: spiderman123.

Where did I go wrong??? I'm going nuts over this is, it's only the 2nd step of the room.

I'm attaching an image below.

https://preview.redd.it/hhdfcrm9odo61.png?width=702&format=png&auto=webp&s=0f41ee656fdd5a3af51a6bc914dd29b541e2061a

bcrypt is a hashing method that uses salt additionaly to the classical hashing, can you crack it with a dictionnary/mask attack, without brute forcing?

Our volunteer community aiming to solve world homelessness, among other things, have just ran into a bug. The last 3 new devs have all failed to set up a local host version of the platform and are getting the same error with bcrypt. Has anyone else seen this and found a solution to it?

Here's the error logs: https://publichappinessmovement.com/t/topic/2631/2

and here's our Github: https://github.com/focallocal/fl-maps

Hello, i recently listened to a conversation, which hinted that it is possible to generate session keys which possess the PFS attribute without relying on DiffieHellman or Generalized Diffie Hellman Protocols. Only with stuff like serpent, HMAC-SHAX and scrypt or argon.

Is this true? If i have understood this wrong, is there somewhere a survey or a tome which lists all current known protocols which posses all PFS attribute?

Si quieres que tu sitio este seguro, Node Bcrypt es una opcion para aquellas personas que mana NodeJS como yo, básicamente funciona bajo el concepto de las tablas de hash, no explicare el tema porque la verdad no me he adentrado en ese tema pero se de alguien que si y les estaré dejando su video explicativo, el modulo viene con funciones de comprobación de una contraseña o realizar promesas, puedes ver su repo en Github.

<https://github.com/kelektiv/node.bcrypt.js/&gt;

Video: https://youtu.be/LluB6jU-SwY

I've seen this statement various times online, usually by two of the judges from the expert panel on the Password Hashing Competition (PHC), where argon2 won and often gets advised as what you should prefer for password storage.

That advice is repeated for websites/apps where a server tries to keep low response times and not tax the server too much that an attacker could exploit it for DDoS for example. With bcrypt and a sufficient work factor to target that time, it's ok. scrypt also has the author advise a target of 100ms, while IETF has mentioned 250ms in a draft.

So what is it exactly about argon2 that makes it problematic below 1 second compute time? It's not related to the parameters so much as the server performing it, as 2 seconds on a VPS would be considered ok, but on my own desktop machine that same hash would be computed within 500ms.

It's not entirely related to the time either, because they say bcrypt is good below 1 second... so I'm left rather confused about this repeated statement advising to avoid argon2 for this use-case.

If anyone needs some actual sources, I can provide some links to those statements (most are tweets by the two judges, or others citing them).

Update:

One of the judges responded below to expand on their reasoning.

It seems that it's nothing to worry about, and was mostly about an attackers hashrate changing based on workload presented, but that appears to be somewhat misinformed as bcrypt has a higher hashrate for an attacker via FPGA (costs less than GPU).

As the parameters increase for argon2, the available memory bandwidth of the GPU begins to bottleneck the hashrate, making it more favorable than bcrypt.

JWT is commonly found in java, javascript while Bcrypt is more common in rails projects. are they used for the same thing? authentication or authorization?

Hi r/crypto,

I'm writing a Java library that supports bcrypt, scrypt and argon2 without JNI (in other words, the algorithms are written in pure Java) in favor of compatibility with different architectures.

I'm quite sure that the implementations are fine in terms of input+parameters/output but I'm looking for a look-up table where I can verify a large amount of data (bcrypt in this example).

I was wondering if such a database existed, where developers can check and be sure that their implementations are compliant to the original specifications.

On the internet I couldn't find anything if not online generators that I have already used for my tests, but I could have missed some (borderline) cases I'm not aware of.

Thanks!

I'm debating what hash function to use. I've always known the math and how a longer password could be used instead of scrypt, but I've always only thought to use scrypt to hash passwords, as it is respected in the industry. I've never really considered using a basic hash function until I saw this wonderful XKCD. Would I be wrong to just use a simple SHA256 with salt and make the password requirement be at least 16 characters? I like that idea a lot better, but would my consumers and peers lose confidence in my product from a social perspective? More importantly, what other password requirements would I have to add to prevent dictionary attacks if my database was exploited? I'm thinking that there must be at least twelve different characters in each password.