Inputs.io Security [Solved] | Bitcointalksearch.org

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote from: MPOE-PR on July 04, 2013, 07:41:14 PM

Quote from: nimda on July 02, 2013, 11:25:30 AM

Quote

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.

Quote from: 🏰 TradeFortress 🏰 on July 04, 2013, 07:57:20 PM

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

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

🏰 TradeFortress 🏰

vip

Activity: 1316

Merit: 1043

👻

Quote from: MPOE-PR on July 04, 2013, 07:41:14 PM

Quote from: nimda on July 02, 2013, 11:25:30 AM

Quote

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.

MPOE-PR

hero member

Activity: 756

Merit: 522

Quote from: nimda on July 02, 2013, 11:25:30 AM

Quote

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?

paroxsitic

newbie

Activity: 37

Merit: 0

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.

tom1

full member

Activity: 130

Merit: 100

Quote from: escrow.ms on July 02, 2013, 12:07:10 PM

Quote from: tom1 on July 02, 2013, 12:05:11 PM

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

escrow.ms

legendary

Activity: 1274

Merit: 1004

Quote from: tom1 on July 02, 2013, 12:05:11 PM

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

Because it's in beta aka testing stage.

tom1

full member

Activity: 130

Merit: 100

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

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote

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.

Topic: Inputs.io Security [Solved] (Read 890 times)