Pages:
Author

Topic: mcx passwords (Read 4356 times)

member
Activity: 81
Merit: 1002
It was only the wind.
August 21, 2013, 12:53:47 PM
#73
I guess the only thing we can do is use a unique password

That is naive.  Say the company (any company) grows and eventually multiple people will have access to the password list.  If it is hashed that provides a level of security against internal theft/abuse.  If it isn't then an employee steals your login credentials, goes home, logs in as you with your unique secure password and withdraws all your coins. 

There is a reason hashed passwords is a security standard.   Password resuse is on vulnerability but it isn't the only one.

You are exactly right, D&T. However, I also understand RealSolid's point of view. The only information users are required to submit (when I signed up, anyway) is a username and a password. Therefore, if people forget their password, they're locked out. Now, RS could deny all password reset requests, but then people would be up in arms about him stealing their money. So, until he implements two factor authentication, I really don't see a better way to do it.
newbie
Activity: 2
Merit: 0
May 24, 2014, 06:01:28 AM
#68
I've lost my password for mcx account. How can I recover it? I've already sent an email with description of my problem to mcx support address, but didn't get response. I've also tried to contact RealSolid on IRC channel, but didn't get any response. Is there a chance to recover lost password for my account ? Anyone have similar situation on mcx site ?
member
Activity: 94
Merit: 10
Operator of mcxNOW | Programmer of MicroCash
August 23, 2013, 12:05:04 PM
#67
That is naive.  Say the company (any company) grows and eventually multiple people will have access to the password list.  If it is hashed that provides a level of security against internal theft/abuse.  If it isn't then an employee steals your login credentials, goes home, logs in as you with your unique secure password and withdraws all your coins. 

There is a reason hashed passwords is a security standard.   Password resuse is on vulnerability but it isn't the only one.

No such threat exists currently because only one person has access to any such data (myself). Employees of any company are expected to treat data in a secure fashion. My bank for instance knows my password and all security questions. Any employee I call has access to that data. More factors of authentication is always good and helps restrict what employees can do though, which I've added in the next update.

I think the biggest weakness with any of these systems is the human element which is why I reduced the need for them to the bare essentials. Handling 10 minutes of support a day for over 7000 accounts isn't too hard for me atm but thinking longer term if the site is very successful then new arrangements will have to be made because I always want to restrict that human element, the biggest weakness.
donator
Activity: 1218
Merit: 1079
Gerald Davis
August 20, 2013, 01:48:03 PM
#66
I guess the only thing we can do is use a unique password

That is naive.  Say the company (any company) grows and eventually multiple people will have access to the password list.  If it is hashed that provides a level of security against internal theft/abuse.  If it isn't then an employee steals your login credentials, goes home, logs in as you with your unique secure password and withdraws all your coins. 

There is a reason hashed passwords is a security standard.   Password resuse is on vulnerability but it isn't the only one.
hero member
Activity: 622
Merit: 500
www.cryptobetfair.com
August 20, 2013, 01:42:14 PM
#65

I guess the only thing we can do is use a unique password



And when unique passwords gets logged by keylogger, Google Authenticator is there to help you protect your funds.

No need to flame, added security should result in higher share-fee payouts.


you are right... I should not try and stir up a bunch of problems over a stupid non issue.
sr. member
Activity: 434
Merit: 250
August 20, 2013, 12:11:36 PM
#64

I guess the only thing we can do is use a unique password



And when unique passwords gets logged by keylogger, Google Authenticator is there to help you protect your funds.

No need to flame, added security should result in higher share-fee payouts.
hero member
Activity: 622
Merit: 500
www.cryptobetfair.com
August 20, 2013, 11:45:21 AM
#63
RS, unless you provide one of these for every user that signs up, your security is total shit!

http://360biometrics.com/iris_image_capture_scanner/crossmatch/I_SCAN_2_Dual_Iris_Capture_Scanner.php


Shit.... I guess a hacker "could" steal our eyes.

I guess the only thing we can do is use a unique password

legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 20, 2013, 05:37:57 AM
#62
Wrong. Here's your solution: Store a user's GPG public key in encrypted form, or hell, even in plaintext. If they request a password reset, do a challenge/response.

No need to encrypt the public key (it is *public* after all) so all that is needed is to create a new random password and then GPG email it (unless the user has had their GPG private key stolen in which case you are no better off than any other automatic reset).
legendary
Activity: 1344
Merit: 1001
August 19, 2013, 06:43:44 AM
#61
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?


Yip just checked many banks do email password resets google it. If you don't have the link http://google.com Oh wait Google does email password resets. Let me check another super insecure company http://Amazon.com OMG password resets what is with the insecurity!

Notice how Realsolid calls people 'laymen' without even knowing the background of the person he is speaking to (myself - 1st class maths degree from an ivy league university and have been a web developer for years). The least Realsolid should do is warn on the new user registration page that he can read the passwords as this will stop most people from re-using passwords. That is the ethically correct thing to do imo until he follows the industry standard of hashing and salting passwords rather than reversible encryption/decryption.

legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 18, 2013, 11:55:24 PM
#60
When a hacker breaks the database do you want your mothers maiden name, social security number, first pet all in the open too? That's ok but a unique password in the wild is just too insecure? I just don't get some people. Smiley

As I also stated I encrypt sensitive information in the DB (including the password hashes) - and the key used (along with a UUID salt) is composed of parts that are all separate from the DB (and can include a compiled in UUID, a UUID in a separate file as well as a RAM only portion - meaning that only an uber-hacker who has root access, can decompile and has a memory dump of the running system would have any real chance of working out how to decrypt anything).

The problem is that users often re-use passwords so if someone managed to crack your encryption then they may well be able to do much more damage than just find what is in your DB.

In regards to your question about automatic password resets I have not yet made a decision (for now only manual resets will be possible). I think for GPG users though this would be safer than for others.
member
Activity: 94
Merit: 10
Operator of mcxNOW | Programmer of MicroCash
August 18, 2013, 11:46:54 PM
#59
I currently do not have any automatic email reset at all (have a look for yourself please - my system is open source after all https://github.com/ciyam/ciyam). I do allow a manual reset (that has to be done myself) which then involves a GPG encrypted email being sent (assuming the user signed up with GPG) or at worst an email with a link to create a new password (the last would only be sent if I am satisfied the reset is genuine which can be done with questions *other* than what they think their password is).

Sorry I thought you did have auto password resets. Are you planning on adding that? What questions do you ask them? You're aware that if a session is stolen all info a user can grab from the site itself is useless to verify right?

Although using C++ does give some big advantages with regards to security it is still *never* a good idea to store encrypted passwords. You can have things like "password recovery question and answers" (regardless of whether you do resets manually or automatically) that do not need to involve needing to know an end-user's password.

You do realize the fact you store anything "personal" from the user, whether it's password or mothers maiden name, or first pet in recoverable form is pretty much the same? Just a different type of fish my friend.

For some reason some people think keeping personal private details about themselves in recoverable form is somehow more appropriate than a unique password. It's kind of interesting to me but I will probably move to a system like that instead because educating laymen is pretty foolish as we can see in this thread.

When a hacker breaks the database do you want your mothers maiden name, social security number, first pet all in the open too? That's ok but a unique password in the wild is just too insecure? I just don't get some people. Smiley

The first rule is to never get broken into and thats what my system is probably best at doing compared to anything else out there.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 18, 2013, 11:30:48 PM
#58
Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?

I currently do not have any automatic email reset at all (have a look for yourself please - my system is open source after all https://github.com/ciyam/ciyam).

I do allow a manual reset (that has to be done myself) which then involves a GPG encrypted email being sent (assuming the user signed up with GPG) or at worst an email with a link to create a new password (the last would only be sent if I am satisfied the reset is genuine which can be done with questions *other* than what they think their password is).

Although using C++ does give some big advantages with regards to security it is still *never* a good idea to store encrypted passwords. You can have things like "password recovery question and answers" (regardless of whether you do resets manually or automatically) that do not need to involve needing to know an end-user's password.
member
Activity: 60
Merit: 10
August 18, 2013, 11:08:53 PM
#57
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?


Yip just checked many banks do email password resets google it. If you don't have the link http://google.com Oh wait Google does email password resets. Let me check another super insecure company http://Amazon.com OMG password resets what is with the insecurity! What my bank doesn't do is give me my password over the phone..... weird I wonder why? I will also note my bank is not C++ and actually delivers on share dividends on time its a crazy concept.

Some use 2FA like most exchanges in crypto offer.... I say most coins-e and MCxnow dont. Pretty sure coinex and cryptsy do as well as every BTC exchange. Email alerts on login? Nope. Email withdraw notification? Nope. I guess these options cant be done in C++ or with your UBER L3EET skills.

But of course the RS is right he has to be speak against him in his little world he bans you belittles you. Then his small army of trolls comes after you. Grow up you little psycho.
member
Activity: 94
Merit: 10
Operator of mcxNOW | Programmer of MicroCash
August 18, 2013, 10:56:47 PM
#56
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?

member
Activity: 94
Merit: 10
Operator of mcxNOW | Programmer of MicroCash
August 18, 2013, 10:54:26 PM
#55
So RealSolid, how your system check the user password when he log in ?
He has to send a request to your password server.
So your password server is not off the internet.
He is just not directly on the internet.
So if a hacker compromise you site, he now have internet access to your password server.

A comparison of password==password. There is _zero_ code to read passwords and deliver them back to the user on the site. This means an attacker would need to create this code to deliver it back to users. ie In a C++ executable they have never seen it's virtually impossible even if there was a way to insert code (a bug).

Then you say "so what, the password should be unique to my site", but imagine the hacker just retrieve the password list and leave, cleaning all his trace.
Then he could empty the accounts on mcxnow even the cold storage ones.

The mcxNOW database works on a single serve mechanism only. This means there is no code to get "all users". I designed the system on purpose to limit any abuse to a single account, not the system. To abuse a single account you will of course need to know a username and password. To abuse all accounts you will of course need to know all user names and passwords and it is impossible to get this information over the internet because I designed the system and there is no code to do such a thing for a hacker to abuse. Do you understand that for a hacker to abuse something there needs to exist code on the site to do the thing to abuse?

So maybe there is a median solution here :
- Hash the passwords that are used to authenticate user loging in.
- Store an offline encrypted list of password, so you can do your manual password recovery stuff.

On a side note I agree with you that user have to trust the admin of a site, because whatever he says, he can watch your password if he wants to.
On the other side you could do the javascript hashing on client side and that would prevent the admin to have access to it.
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...
 

The point is there is no difference in my setup whether I hash passwords or don't. There is zero security benefit. Furthermore unlike other exchanges which have weak email password resets I do all password resets manually to protect my users, at the cost of my time. The security at mcxNOW is higher than every other exchange in my (and others) opinion, regardless of what a couple of PHP/SQL laymen think about how secure hashing+salting a password is.

The people here who talk up hashing passwords and in same breath recommend weak email reset systems make me laugh. Most banks keep your passwords in encrypted form, you better stop using your banks too!
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 18, 2013, 09:13:33 PM
#54
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

On the server side (for storage) the password hash is encrypted with a UUID for salt so that even in the event of the DB being stolen rainbow tables will be of no use.

I wonder how bitcointalk.org stores and retrieves our passwords?

The password is passed in the clear (through SSL of course) to the server side where it is hashed iteratively and compared against the hash in the DB (thus the password cannot be retrieved - only hashes compared).
member
Activity: 60
Merit: 10
August 18, 2013, 03:48:49 PM
#53
um hello this thread should never die
sr. member
Activity: 261
Merit: 250
Interesting.....
August 18, 2013, 02:23:50 PM
#52
I find password drama...interesting....

I wonder how bitcointalk.org stores and retrieves our passwords?
legendary
Activity: 1344
Merit: 1001
August 18, 2013, 12:57:36 PM
#51

Then you say "so what, the password should be unique to my site", but imagine the hacker just retrieve the password list and leave, cleaning all his trace.
The he could empty the accounts on mcxnow even the cold storage ones.


This is a good point. If RS has done things properly the cold storage funds won't be accessible and only the hot wallet would be affected by this. Although until RS realised/accepted that his db had been compromised, the hacker could just keep emptying the hot wallet everytime RS filled it back up.
legendary
Activity: 1344
Merit: 1001
August 18, 2013, 12:50:41 PM
#50

mcxNOW has no "Remote database", which means everything is incorporated on the one machine which doesn't have internet access. Secondly the reason hashing passwords is a "gold standard" is because everyone uses databases like SQL which have been hacked to death since the internet began. mcxNOW doesn't use these systems, it uses a custom database and the exchange server cannot be accessed on the internet. There is zero code to read passwords on the site which means it is impossible for an internet hacker to obtain passwords. Therefore the only way to get into the system is to be at the datacenter, then to understand the encryption, to reverse the binary, etc. This is beyond ludicrous to suggest it's a more probable event compared to any other system out there.


No it's beyond ludricous to suggest it's not possible there are holes in your security measures outside of a dodgy datacenter. It's laughable you think it's impossible there might be a hole somewhere you haven't thought of. The probability is non-zero, fact.

Multi-billion dollar companies with teams of the best minds in the industry have had their db's compromised by hackers, you're deluded to have your main argument as "welp we can't be hacked anyway LOL".

Meanwhile a typical exchange site that uses SQL can be broken from the internet. Yet if the SQL site uses password hashing it's somehow a "gold standard" compared to mcxNOW? Please. mcxNOW is *THE* standard because every single packet of information is controlled by the code from one person, I know everything that goes on within the exchange. There are no black boxes like others use in their php/sql/asp.net setup.
This is complete fluff in relation to my post. As far as 'gold standard', the SQL site that using password hashing and salting per password is doing a superior job to mcxnow in terms of password storage. Every single packet of information nonsense is simply irrelevant to what we are talking about here. Encrypted passwords could be retrieved in plaintext form by a hacker at your exchange Realsolid, however small the possibility, it's still a possibility. Honestly I'm not wanting to be rude here, but do you not understand this concept?

And email systems are ridiculously insecure. If an email is hacked from ANYWHERE then they can reset your exchange password and steal all your funds. Say you check your email at your mothers house and she has a virus. They log into your email, see you use mtgox and reset password. 24 hours later your account is drained. Your main PC doesn't even have to be compromised and email systems are among the highest compromised websites in existence. Most people probably aren't even aware their emails are hacked.

I addressed this point in my original message in anticipation of you making this weak argument. Yes you could check your email on a computer that has a virus. In the same way you could check your mcxnow account on a computer that has a virus. By extension that makes your own site 'ridiculously insecure'. If you have a keylogger on your machine you think the keylogger will collect the email password but never the mcxnow password? That makes no sense at all.

Your claim that email reset systems aren't insecure if "used properly" is easily extended to using a unique password at every site you use. It's really not that hard and the only reason you shouldn't be doing it is ignorance, not laziness.
The distinction between the two is if you implemented an email reset system properly the onus wouldn't fall on the customer but instead on the person who is responsible for running the exchange.

Just using a unique password would make this a zero probability.  This is such a non issue.

That doesn't make any sense in relation to what I wrote:

Quote
It is therefore a non-zero probability that a hacker could gain everyone's passwords by your poor decision to employ encryption; using hashing+salting would make this a zero probability.

If everyone used a strong, unique password (never going to happen) the hacker gaining access to all those passwords would still be a non-zero probability. I guess what you tried to say is, if everyone used a strong, unique password then it wouldn't matter if a hacker gained access to everyone's passwords - however people do re-use their passwords unfortunately, a good programmer would design for this and use the standard approach of hashing and salting - it's very, very little effort. This is all completely standard, textbook web programming stuff you'll find on any book or lecture on the subject.

Do not confuse me as someone who is claiming the exchange is insecure. I am simply explaining that their password storage procedure is crap.

As a separate note, ethically Realsolid should say on his sign up page that passwords can be decrypted to their plaintext format by the admin and are thus readable by him. Because that is the case here. It will also encourage and explain to users one reason why they have to use a unique, strong password just for mcxnow.

Pages:
Jump to: