I have just pressed 'forgot password' on hosting24.com, only to have my password emailed to me in plain text (see image below). I contacted their technical support to question this and they have told me:
We are using Salt encryption on our website, passwords are not stored
in plain text. Please let us know if you have any concerns regarding
the security of your data.
The way I understand it, is that once a password is 'salted' it cannot be reversed back to plain text. I am also very concerned, considering their partner company 000webhosting was victim of a massive hacking incident recently, which exposed that their security was sub-par.
Thanks.
EDIT:
After a few heated emails I finally got this response:
Our passwords are encrypted with a secure encryption method in the
database. Although we do have a decryption method in place (that is
used to prevent fraud), all this is going to change as we are
re-designing the project and updating the code to adhere to new age
standards. We are sorry to have let you down on this one.
Please contact us with any additional questions. Happy holidays!
'New age'. Amazing.
EDIT:
I sent the website this link to prove a point, so I anticipate a load of down votes from their tech support.
Salted hashed passwords are not directly reversible—that's the point of hashing. However one can always try to recover them through brute force, trying all possible/likely passwords to see if the hash matches.
How expensive that is to do depends on the strength of the hash used, but you would never build a system that stores and decrypts passwords that way. If they said they were storing only salted hashes, and still were able to send you the password you originally set yourself, they're clearly lying.
They don't mention hashing though:
We are using Salt encryption on our website, passwords are not stored in plain text.
“Salt encryption” isn't a thing, but let's be as generous here as we can.
It is possible they mean they're using reversible encryption with some randomised element (variable IV, or extra data in the encrypted message) which would ensure two passwords don't get matching encrypted versions (ie the same purpose as the ‘salt’ in a hashing operation).
It's also conceivable that there could be some valid reason why they need reversible passwords, for example if they need to use the passwords to authenticate to another separate system. It's possible to build reasonable systems with reversible passwords, but compared to Good Old Bcrypt it's a whole lot more effort to manage this way (eg keys on the application server; wide-ranging internal policies to manage that; HSMs; and watertight code auditing).
Let's say we accept that this is what they've done and they've implemented it solidly (which is highly doubtful—much more likely they've got plaintext passwords or a hacked-up and vulnerable AES). Even then, they've then blown it by sending you the reversed password in a mail over the unencrypted public SMTP infrastructure.
There are things you can do to mitigate the untrustworthiness of the mail channel, such as sending a single-use token or temporary password that requires a new password to be set afterwards. But there is never a good reason to send an existing password, that will continue to work on the target site and which you might have used to secure other services. User-set passwords should never touch SMTP.
No, they can't without astronomical computing power. I'd bet large sums of money that they have a second database of plaintext passwords.
Related
A friend of mine and me are having a discussion about whether we should pre-hash the passwords of the users of our webapp before sending it to our servers.
I know that there are multiple questions that already handle this topic but they're all about transferring it securely to the server. Our idea is not about the transfer security (we use SSL) we want to hash clientside to prevent that the "real" passwords reach our server.
The idea came as Twitter announced their bug that caused passwords to be printed to a logfile in cleartext.
We are currently discussing about whether this concept makes sense or not and how it affects the security of a password (in terms of Bruteforce) if we would hash it with SHA512.
TL;DR:
We want to hash passwords clientside to prevent our servers from getting them in cleartext (we use SSL for transfer).
Does this make any sense?
What algorithm would be best to use for hashing?
The hashed passwords would then serverside be hashed again with bCrypt.
It 100% makes sense: in fact, the concept has been proposed by a number of people, but the difficulty is in implementing correctly. There are a number of pitfalls if you do it wrong, the most direct one is being vulnerable to "pass-the-hash" as #swa66 describes. To prevent that, you need to hash on both sides. The client-side hash should be slow (bcrypt, scrypt, argon2, or pbkdf2) whereas the server side hash should be fast (sha256).
EDIT: A number of people have down-voted this without understanding how this works, so I now include the basic details here (previously I only linked to how this works). The idea is to apply a slow hash such as bcrypt on the client side, and then a fast hash such as SHA256 on the server side. The fast hash is required to prevent pass-the-hash attacks. In the event of the database leak, an attacker either hash to invert the fast hash (impossible -- violates the one-way property of a cryptographic hash function), or brute force the preimage to the fast hash (impossible -- the size is the length of the output from the slow hash, for example 184-bits for bcrypt), or brute force the combination of the slow hash and the fast hash -- which puts the attacker back at the same position as if the entire computation had happened server side. So we have not reduced the security of password attacks in the event of a database leak by shifting the heavy computation to the client side.
I've surveyed a number of proposals like this in Method to protect passwords in databases for web applications. Additionally, I analyse the pros and cons and identify weaknesses that have not been identified before (account enumeration), and propose a unique way of doing this securely. The research is built off a number of sources, including:
Secure authentication: partial client-side key stretching… please review/criticize my idea
How to securely hash passwords? -- see section on Client Side Hashing
Client side password hashing
Discussion from various authors on Hacker News -- see comments from oleganza, mschuster91, crusso, etc...
You cite the Twitter example, and GitHub did similarly. When I wrote the paper above, the most prominent example for preventing a server from seeing the clear text passwords was Heartbleed, which I comment on in the paper (bottom of Section 1.3).
There has been subsequent follow up research by others identifying similar ideas -- Example: Client-Plus-Server Password Hashing as a Potential Way to Improve Security Against Brute Force Attacks without Overloading the Server. No one person deserves all the credit, but the main takeaway is yes it is a good idea if you do it securely, but you really need to understand the risks (it is easy to do insecurely if you have not read the research).
While #swa66 outlined how to manage passwords securely, let me note that there is a valid scenario where you can consider client-side password hashing, so don't just blindly follow "best practice", try and understand it first.
Let's say I have a standard web application that stores data from users. In my threat model, I don't even want my own users to have to trust me, or in other words, I want my users' data to be secure even in case of a full compromise of my servers. Therefore, I let them choose a password, and encrypt their data on the client, before sending it to the application. They can retrieve their encrypted data with their user id. Well, that doesn't sound very secure, I can just download anybody's encrypted data and run offline attacks against it. So let's have them access their encrypted data with their password (I don't want them to have to remember two different passwords). But that's not good, because I have their password then to decrypt their data. So one simple solution is to encrypt their data with their password, and send it to the server along with their hashed password, which as it's correctly noted in the answer is the new password as far as the server is concerned (so the server should store it hashed once again and so on). However, the server has no way to decrypt client data, because it never has the original password, yet only the valid person can download even their encrypted stuff, and they only have to remember one password. (Note that this is a very much simplified model, in reality, much more is needed, like for example a proper key derivation function, not just plain hashes, but that's another, much longer story.)
Don't get me wrong, I'm not saying you should normally be hashing passwords on the client - no, the other answer is the correct one in that regard. I just wanted to show that there is at least one use-case where client-side password hashing is a valid option. See well-known password managers, some work similarly.
NO!
Rule one in cryptography: do not invent it yourself, you'll make horrible mistakes.
It's not against you personally, by far not: even top notch experts make mistakes when designing with great care new systems. That's why they peer-review each-other's work multiple times before anything become a standard. Many proposals for such standards by such experts get redrawn due to problems detected during such a peer-review. So why can't the rest of us mere mortals design: there's nobody good enough to do the peer-review as the experts will not touch it.
Hashing the password client side
Hashing client side is really bad as the hash becomes the password, and now you store it on the server in the clear.
How to do passwords
Only store hashed passwords (implied: send the password to the server, just do not store it)
use a salt and store it with the password (unencrypted). The salt is essentially a random string that you concatenate to the pasword before you hash it (to store it , and to verify it)
Use a SLOW hash. Using a fast hash is a common and fatal mistake, even when using salts. Most hash functions people know like SHA-256, SHA-3 etc. are fast hashes and completely unsuitable for hashing short, predictable items like passwords as they can be reversed in a surprising short time.
How slow: as slow as you can afford. Examples of slow hashes:
bcrypt, PBKDF-2 (which is essentially a high number of rounds of a
fast hash to make it slow)
There are -depending on your programming environment- pre-made routines, use them!
Ref:
https://crypto.stackexchange.com/questions/24/what-makes-a-hash-function-good-for-password-hashing
https://crypto.stackexchange.com/questions/59797/authorities-on-password-hashing-best-practice
I have read the following article http://lifehacker.com/5919918/how-your-passwords-are-stored-on-the-internet-and-when-your-password-strength-doesnt-matter
There are a number of ways a site can store your password, and some are considerably more secure than others. Here's a quick rundown of the most popular methods, and what they mean for the security of your data.
Method One: Plain Text Passwords
How It Works: The simplest way a site can store your password is in plain text. That means somewhere on a their server, there exists a database with your username and password in it in a human-readable form (that is, if your password is testing123, it is stored in the database as testing123). When you enter your credentials on the site, it checks them against the database to see if they match. This is the worst possible method, in security terms, and most reputable web sites do not store passwords in plain text. If someone hacks this database, everyone's password is immediately compromised.
Does My Strong Password Matter? No way. No matter how long or strong your password may be, if it's stored in plain text and the site gets hacked, your password is easily accessible to anyone, no work required. It still matters in terms of hiding your passwords from, say, your friends, or others that could easily guess it, but it won't make any difference if the site gets hacked.
Method Two: Basic Password Encryption
How It Works: To add more protection to your password than plain text provides, most sites encrypt your password before they store it on their servers. Encryption, for those of you that don't know, uses a special key to turn your password into a random string of text. If a hacker were to get hold of this random string of text, they wouldn't be able to log into your account unless they also had the key, which they could then use to decrypt it.
The problem is, the key is often stored on the very same server that the passwords are, so if the servers get hacked, a hacker doesn't have to do much work to decrypt all the passwords, which means this method is still wildly insecure.
Does My Strong Password Matter? No. Since it's easy to decrypt the password database with a key, your strong password won't make a difference here either. Again: this is in terms of the site getting hacked; if you have a nosy friend or family member rooting through your stuff, a strong password can help keep them from guessing it.
Method Three: Hashed Passwords
How It Works: Hashed is similar to encryption in the sense that it turns your password into a long string of letters and numbers to keep it hidden. However, unlike encryption, hashing is a one way street: If you have the hash, you can't run the algorithm backwards to get the original password. This means a hacker would have to obtain the hashes and then try a number of different password combinations to see which ones worked.
However, there is a downside to this method. While a hacker can't decode a hash back to the original password, they can try many different passwords until one matches the hash they have. Computers can do this very fast, and with the help of something called rainbow tables—which is essentially a list of trillions of different hashes and their matching passwords—they can just look up the hash to see if it's already been discovered. Try typing e38ad214943daad1d64c102faec29de4afe9da3d into Google. You'll quickly find that it's the SHA-1 hash for "password1". For more information on how rainbow tables work, check out this article by coding guru Jeff Atwood on the subject.
Does My Strong Password Matter? In this case, yes. Rainbow tables are made up of passwords that have already been tested against hashes, which means the really weak ones will be cracked very quickly. Their biggest weakness, however, isn't complexity, but length. You're better off using a very long password (like XKCD's famous "correct horse battery staple") rather than a short, complex one (like kj$fsDl#).
Method Four: Hashed Passwords with a Dash of Salt
How It Works: Salting a hash means adding a random string of characters—called a "salt"—to the beginning or end of your password before hashing it. It uses a different salt for each password, and even if the salts are stored on the same servers, it will make it very hard to find those salted hashes in the rainbow tables, since each one is long, complex, and unique. LinkedIn is famous for not using salted hashes, which brought them under a lot of scrutiny after their recent hack—had they used salts, their users would have been safer.
By reading the above article i have the following questions in mind
1.Even if i do not have the password,i still can intercept the message digest......i dont even need the password ...i will simply launch reply attack(ie. send message digest itself for authentication after intercepting it!!)
the solution to above problem can be solved by following way
a.server genrates a random string(usually known as challenge) to the user and asks him to encrypt it with his password .....
b.user enters his password,message digest of the password is created ,random string is encrypted by this message digest
c.this encrypted string is sent to server.
d.server also encrypts random string with message digest of user,checks it with encrypted string recieved from user,if both match,he is valid user..!
2.My question is If the hacker gets access to the database,he will get access to the messagedigests/even if he does not get access to database,he can still obtain message digest while intecepting communication link when user first registers to DB......how this can be prevented??
Even if i do not have the password,i still can intercept the message digest......i dont even need the password ...i will simply launch reply attack(ie. send message digest itself for authentication after intercepting it!!)
This shouldn't be possible.
The client should send the real password to the server. It should be encrypted using SSL.
The server should hash the password and compare it to the stored, hashed password.
the solution to above problem…
That is, more or less, part of what SSL does.
My question is If the hacker gets access to the database,he will get access to the messagedigests
This is a relatively insignificant problem. The passwords should be stored as hashes with varied salts. The original passwords are protected.
even if he does not get access to database,he can still obtain message digest while intecepting communication link when user first registers to DB
Only if SSL is broken.
User registration should always be done through an SSL tunnel, so generally when following best practice you never have to worry about man in the middle type attacks.
I need to make a log-in system and having basically no previous knowledge of how it's done (with security in mind) I studied it on the internet. The way I would do it now is something like this:
Server has login information in a database table - username and a password hash per user (encrypted with SHA224 for example).
When client wants to authenticate, password is encrypted with SHA224 (client-side) and sent with username to the server to verify a match in the database.
If the user ticked "Remember me" option, an authentication key is generated on the server, inserted into a database along with the IP of the client.
The authentication key is sent to the client and stored in cookies.
Now, when the client returns, authentication key from cookies is sent to the server, the server finds it in the database and checks if the IPs match as well. If it does, the user is authenticated and a new authentication key is generated and sent to the user (and stored in cookies) for next visit.
My questions are:
How does encrypting password make this any safer? The hash still can be captured on the way from client to server and misused just as well as if it was plaintext. I know that this is an elementary question but I somehow couldn't find an answer to this one.
Is this security system secure enough? (or better yet - Did I get it right?)
Why does hashing a password make the system more secure
Hashing is not equal to encryption. Encrypted data can be decrypted back into plain text. Hashed data cannot be decrypted.
By hashing your user's passwords, nobody can see what passwords are used. So if your data gets stolen, the hashes cannot be decrypted by the hacker. The same goes for the system administrator, he/she cannot 'lookup' a password. This can be an all to common scenario in shared hosting environments.
Storing passwords
The easiest way to get your password storage scheme secure is by using a standard library.
Because security tends to be a lot more complicated and with more invisible screw up possibilities than most programmers could tackle alone, using a standard library is almost always easiest and most secure (if not the only) available option.
The good thing is that you do not need to worry about the details, those details have been programmed by people with experience and reviewed by many folks on the internet.
For more information on password storage schemes, read Jeff`s blog post: You're Probably Storing Passwords Incorrectly
Whatever you do if you go for the 'I'll do it myself, thank you' approach, do not use MD5 anymore. It is a nice hashing algorithm, but broken for security purposes.
Currently, using crypt, with CRYPT_BLOWFISH is the best practice.
From my answer to: Help me make my password storage safe
As for the infamous remember me option.
Create a random token and give it to the user in the form of a cookie.
If the user presents a cookie with this token, you give them access. Key is to only accept each token once. So after it is used, replace it with a new random token.
This token is, in essence, just another password. So in order to keep it safe, you do not store the token, but a hash of it. (just as you did with the password)
Your suggestion of binding the cookie to an IP-address will unfortunately not work. Many people have dynamic IP-addresses, some even change from request to request during a single session. (this is for example caused by load-balancing proxies).
Sending passwords to the server
The only method currently usable for sending a password from a web browser to server is by using a SSL-secured connection. Anything else will not be safe, as you cannot guarantee the integrity of the solution on the client side.
Some points I want to add:
the hashing of the password is not done on the client. You cannot do it reliably. The necessary technique for computing the hash (JavaScript in your case) might not be available and you cannot trust the result. If somebody can retrieve the hashes of the passwords in your database he could just login without knowing the actual passwords.
make sure to use SSL or another secure transport for transmitting the given passwords from the client to the server. SSL is a good idea for everything after all.
you should not use a single hash algorithm for storing the passwords in the database. Have a look at HMAC. That is far better. Additionally read about salts in cryptography.
Never ever invent your own crypto
mechanisms. Use someone else's.
Crypto is beyond tricky, and unless
you're Bruce Schneier, you have an
extremely slim chance of improving
it, while having a huge chance of
screwing it royaly.
Do not encrypt passwords, hash them.
If you're using hashes, salt them.
If you don't have
to use straight hashes, use HMAC,
they're much more resistant to
precalculated attacks.
If you're
sending stuff across an unsecure
link, add a NONCE to the transmission
to prevent replay attacks. This goes
for both client->server and
server->client.
If you're using salts and nonces, make sure they have high entropy. 'secret' is not a good one. Make it random, make it long, make it use large character sets. The extra computation cost is minimal, but the security you gain from it is enormous. If you're not sure how, use a random password generator, and then use ent to measure entropy.
Do NOT use a
timestamp as a nonce, unless you have
a very specific need and really know
what you're doing.
Use session
protection. SSL isn't perfect but
it's helluva better than nothing.
If you're using SSL, make sure to disable weak protocols. SSL session starts with 'offerings' of lists of ciphers both sides can do. If you let clients use a weak one, an attacker will definitely use that.
I am new to web development. Am I allowed to store users' original passwords? I know good practice is to store the hashed password using a salt, but why don't we store the original password?
Is it because the database is easily hacked, so hashing protects passwords? Are there any other reasons? If not, I would like to store the original password if it is legal to do so.
The legality depends on the country you live in. But there are best practices, too. And a best practice is to encrypt user's passwords. In this way, if someone breaks into your database, they will not be able to obtain the long list of passwords, and try each one of them in ebay, yahoo mail, and gmail. Users generally use the very same pair of username and passwords for many sites.
As Jon points in the comment, of course there is difference between hashing and encrypting. Hashing is a one-way, data-destructive process, which takes an arbitrary-length string as input, and outputs a fixed-length string. This string is defined in such a way, that changing any single bit in the original input, will cause the hash to be different. If you have a hash, therefore, it is not possible to reconstruct the original text (i.e. it is not possible to recover the password).
On the other hand, encryption proper is a technique where you can recover the original password, knowing secret keys, passwords, etc.
Usually, you want to hash passwords, not encrypt them: it's not necessary, and it is more complex to setup. You are not supposed to recover password either: you will just regenerate them.
Imagine if Facebook was hacked, it didnt encrypt any of the user's passwords. Facebook itself has around 200 millions(?) users
What if all of the 200 million passwords were leaked to some evil organization? Many users use same password as their mails or any other sensitive online services such as bank accounting.
Facebook wouldn't be safe at all once. Would you register an account there?
I don't know if it's legal, but nonetheless I would advise against it for at least three reasons:
This is not only about hackers getting access to your passwords. Users often have the same password for multiple accounts (also they shouldn't have). So who says we can trust you or other people who have legal access to this data?
It doesn't matter how secure you think your server is. There is no such thing as absolut security for a server. You should consider that it could be hacked eventually. And don't believe it'll never happen. Hope for the best, but always plan for the worst!
I would use every easy and cheap security I can get to secure not only my data, but also the data of the users. And the method of using a salt+hash is cheap. It will cost you 2 lines of Code. It
Yes, it's perfectly legal, though absolutely not recommended to store passwords in plaintext. And it's not that your actual live database can be compromised: even a backup copy can be stolen (without you ever knowing it).
When passwords are stolen, this is very bad for your actual users, since very few of them actually use different passwords for different sites.
It is legal according to the law. Some companies store the password in plain text, so that it is recoverable.
However, for safety reasons this is a bad idea. Once in a while, some company gets hacked and their database is accessed. In some cases, this exposes the passwords of thousands of users. This will severely damage the image of your company, and is even more a security risk when the password is not hashed.
If you want the password to be recoverable, at least encrypt it so that it is not easily viewable by accessing the database.
The original password isn't stored because once the database has been hacked your vulnerable information is at risk including your password so encrypting will not do anything once they have access through other sources. Depending on where you live some sites will store your password in plain text, For example, if your password is Appletree1234 they will stored your password in plain text as Appletree1234. According to Lifehacker.com, when you enter your credentials on the site, it checks them against the database to see if they match.
If you were to hash a user's password prior to sending it across the line and leaving it in plain-text in memory, would this improve the security of the application?
I would assume this mitigates a small fraction of vulnerabilities by protecting the data stored in the clients memory. But really if we're worried about someone reading the client's memory there are probably bigger problems that we can't address.
There's something that doesn't feel right about hashing on the client's end.
Is password hashing on the client end a common practice? Are there any other advantages or disadvantages to doing it?
EDIT:
Given the communication channel is secure (SSL). Under what conditions would it be acceptable and worthwhile to use such an approach. I'm asking this because it was suggested by a "security professional" that I use such a scheme during some application functions.
No.
When the client sends something, whether it is P or H(P) or H(H(P)) anyone who intercepts this can simply resend the exact same thing, thus making any function like this equivalent to using the password directly.
That's why you should use a nonce; The server can give out some random garbage k and the client will calculate H(P,k) and send it to the server. HMAC is a popular implementation of this method.
Provided the server never accepts the same nonce twice, this is secure against a replay attack.
Sending a hashed password won't improve security on your site, as others have pointed out (since you accept a hashed password, all the bad guy needs to know is the hashed version). It's also not really secure, since the bad guy can presumably load your login page and examine the Javascript or Java deployed.
What it does do is prevents somebody watching the packets from being able to pull out a password, and that is moderately useful. Many people use the same password on multiple sites (I do it for all but the higher security sites), and therefore if you can get one password from them you can log into other accounts on other sites.
It also prevents the real password from being stored, even temporarily, on your site, and that may provide a little extra security if your site is compromised.
So, while I'd consider user-side hashing to be potentially a good things, it isn't worth going to much extra trouble.
And, as others have told you, don't roll your own security. There's far too many things that can go wrong. You won't notice them nearly as fast as a practiced bad guy will.
The hash is identical to the password from a security POV in the scenario you describe: if I intercept the hash, I don't need to know the password, I can just send the server the hash I intercepted.
Authentication protocols go to some length to avoid this problem; security is hard, and you are best off selecting and implementing a well-understood protocol rather than rolling your own.
If your traffic is going over SSL, you're safe from interception and hashing gives you little extra benefit.
Yes, you should.
IEEE had a data breach in which 100K emails and passwords were exposed from a weblog.
http://ieeelog.com/
Obviously, IEEE should not have exposed their weblog! But if they had hashed the passwords at the client side, this wouldn't have been nearly as bad.
As the first answer states, you should use a nonce. If you use a long enough nonce (e.g. 128 bits), you don't really need to worry about reuse, as the server will never ask for the same nonce twice (assuming correctly seeded CRNG, etc.).
No, hashing at the client does not protect the password 'completely'. When one opts to hash the password at the client, then the digest submitted to the server, essentially becomes the password. This is not a problem in itself if SSL is deployed.
However, this scheme ends up creating more problems than it solves. If the server were to compare the hash submitted by the client with a stored hash in the database without performing any further cryptographic operations (especially hashing the input data), then the password is stored in clear text for all practical purposes. Any person with access to the stored hash can re-submit it to the server and gain access to accounts.
In simple terms, if the submitted hash (which is the same as the submitted hash) were to leak via any other vulnerability within the application (via SQL injection, for instance) then the application has a vulnerability where in it protects the passwords inadequately.
If the underlying vulnerability must be fixed, then it is necessary to treat the submitted hash as a password in clear text, which should then be hashed (with a salt preferably) before comparison with a stored hash.
I think it makes sense in one circumstance; you don't want to even know the client's plaintext password. If you hash at the client side, then salt and iteratively hash that hash the same way you would a plaintext pw. Other than that, its kinda silly.
Just make sure that you are sending your password through a secure channel (SSL). If the client can have an application private memory read, then most likely they have bigger problems, like for example a keylogger.
You'd be much better off if you used the Secure Remote Password protocol (SRP). It was designed for this.
I can give you different kind of approach
If you have not SSL you can hash password on client side and again it hashed on server side using another hashing method and store them on database
and when user login with password do the same process and match double hashed password with stored hashes
Yes it makes sense to hash the password on the client side even if you use SSL but still you must also hash it again on the server side.
This makes sense especially in case of a mobile app. If you hash on the client side even with a "constant salt"/domain string it will be much better than sending a password in plaintext even if you use SSL. If you send plaintext passwords to the server then in case someone hacks your server he will receive password in plaintext. So adding additional pre hashing on client side protects the users and their password which they probably use also in other places.
You will probably find many posts saying that client side hashing is not needed but they usually are related to a web apps and do not consider mobile app case. In case of a web app if someone hacks the server he can replace the website and remove the client side hashing anyway so in such case there is not that big advantage. But for mobile apps an attacker cannot replace code of the mobile app so hashing on the client side has a lot of sense in such case.
You can check this link for a possible solution with hashing on both client and server side: https://medium.com/#harwoeck/password-and-credential-management-in-2018-56f43669d588
So yes, hash on both client and server side.
Hashing on the client side opens up another huge hole: you may expose the hashing algorithm. You don't say whether this is web-based (client=JavaScript) or thick-client, but you're giving them more information. Given the channel is secure, you don't have to worry about the clear text password being sniffed.
Besides, if your hashing algorithm requires a salt, you would be exposing your salt, which means if they ever got access to the database, they would be able to decrypt every password.