1. Would it be safe to build a password hash like crypt() based on 3DES today?
Maybe, kind of, it depends, don't do this. "Based on" is key here. You'd have to come up with some way to try to use 3DES in this fashion, just as the developers of Unix crypt() used DES. Basically you're trying to build a cryptographic hash out of a primitive that's not really intended for that purpose, you also need to add more salt than the Unix team did back then, and then you need it to run very slowly, preferably on everybody's hardware not just the generic (likely x86-64) general purpose CPU you're using. Lots of people already built _good_ ways to do password hashing in the 21st century, and if none of those are available somehow you should just use PBKDF2 with SHA256 and a nice big iteration count and that'll be tolerable.
2. Oh, I didn't realise, I just meant is 3DES fine for encryption?
You should not do this. The main thing wrong with DES is the key size is too small, which 3DES fixes (effective key size with full 3DES is 112 bits, which is very short today but probably not the biggest hole in whatever security system you're building). But the next biggest thing wrong with it is that it's a block cipher with a small block size, 64-bits. 64-bits is small enough that bad guys may be able to collide your blocks and set fire to everything. To avoid this: Don't use 64-bit block ciphers, go get a real cipher like AES that uses 128-bit blocks. Done. Why are you still here? Could it be secure if you can defuse the collision risk (e.g. you only encipher very small amounts of data)? Sure, but now you're defining the problem to make the choice of primitive look safe, which is always a terrible idea.
It’s probably safe from the casual attacker who just downloads a password list and runs a one word dictionary attack, but for a dedicated attacker, let alone a nation state, it’s not secure.
TL;DR: Just use AES. Even an ASIC isn’t powerful enough for that. Searching the entire key space would take more energy than the universe has. Compare that to DES that can have its entire key space searched in a few days.
Edit: you said triple DES, not single. My point still stands. DES, even 3DES, is not secure. If I can crack a DES password in 4 days, I can crack a 3DES password in 12. AES with a strong password is virtually uncrackable.
It's multiplicative, not additive. 3DES is about 2^56 times as difficult to crack as DES. (Not 2^112 times because there is an attack that effectively limits it to twice the effective bits of DES, rather than the three times you might expect at first).
* Meet-in-the-Middle attack.
This attack is surprisingly simple, if you encrypt the message twice by
ciphertext = encrypt(encrypt(message, key1), key2)
decrypt(ciphertext, key2) == encrypt(message, key1)
But in this case, the attacker can obtain all the 2^56 possible encryption of message by enumerating key1, put it in a lookup table (assume the table-lookup time is O(1)) , then we can try all possible decryption of ciphertext by enumerating key2. Then compare it with the lookup-table for a match, bingo!
If key is 56-bit, the attacker gets 2^56 outputs for the left side, 2^56 outputs for the right side, total number of operations is 2 x 2^56 == 2^57, not 2^112.
To increase the security claim to 2^112, we need triple encryption, not double encryption, thus 2DES is never used.
The idea that simple double-encryption doesn't work because of such a simple attack shocked a lot of newcomers.
If you’re using 3 different keys, yes, that makes sense. But if you’re just keystretching one key, wouldn’t it just take 3 times as long because you encrypt, decrypt, encrypt (3 processes)?