Inputs.io Security [Solved]

[nimda]

Passwords hashed with SHA256 before sent to the server - we never know your password

This concerns me slightly. The whole point of a hash is irreversibility once the server is compromised. However, this just uses the sha2 as the password. It's therefore a step forwards in some areas and a step backwards in others, unless the server takes the hash of the hash once received.

[tom1]

I'm wondering why there isn't an official thread about Inputs.io?

[escrow.ms]

I'm wondering why there isn't an official thread about Inputs.io?

Because it's in beta aka testing stage.

[tom1]

I'm wondering why there isn't an official thread about Inputs.io?

Because it's in beta aka testing stage.

Hmm, it looks like it was released today: https://inputs.io/news#n-2

[paroxsitic]

I have confirmed via HTTP recording they do send just a SHA256 hashed password over the network (with no salt). It would indeed be more secure to salt your pin code you entered in a way that would not be obvious to someone who was sniffing around.

None the less, hashing a password before it's sent in a POST is more secure most non-financial sites.

I can only hope they do some sort of unique salt when storing the password to their database.

[MPOE-PR]

Passwords hashed with SHA256 before sent to the server - we never know your password

This concerns me slightly. The whole point of a hash is irreversibility once the server is compromised. However, this just uses the sha2 as the password. It's therefore a step forwards in some areas and a step backwards in others, unless the server takes the hash of the hash once received.

There's no real reason to suspect they aren't taking the hash of the hash is there?

[🏰 TradeFortress 🏰]

Passwords hashed with SHA256 before sent to the server - we never know your password

This concerns me slightly. The whole point of a hash is irreversibility once the server is compromised. However, this just uses the sha2 as the password. It's therefore a step forwards in some areas and a step backwards in others, unless the server takes the hash of the hash once received.

There's no real reason to suspect they aren't taking the hash of the hash is there?

This.

We use bcrypt on the server side, with a user unique salt.

[nimda]

Passwords hashed with SHA256 before sent to the server - we never know your password

This concerns me slightly. The whole point of a hash is irreversibility once the server is compromised. However, this just uses the sha2 as the password. It's therefore a step forwards in some areas and a step backwards in others, unless the server takes the hash of the hash once received.

There's no real reason to suspect they aren't taking the hash of the hash is there?

The phrasing of the FAQ had me worried.

We use bcrypt on the server side, with a user unique salt.

That's good, thanks. I'll lock the topic.