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.