Tag Info

New answers tagged

1

I have not used these technologies before but what I can tell you is if you decrypt the password in your SQL query then anyone on your network can sniff and get the passwords as plain text. If I understand correctly, your C# will get the decrypted passwords? If so I would recommend you have something such as in your C# application: C# generate a random ...


8

Actually quantum computers are not that much a threat for symmetric encryption. To put it in simple (and somewhat simplistic) terms: A quantum computer, if it ever exists, will totally break the most used asymmetric encryption and key exchange algorithms (RSA, ElGamal, Diffie-Hellman...) but not all asymmetric algorithms (QC does not break the concept of ...


3

I have used a similar method in the past: I had a plain-text file containing my credentials and encrypted this with the Blowfish cipher. Now I use KeePass, an offline password manager. I strongly recommend it, as it is Much more user friendly than an encrypted text file, and Much more secure than a text file encrypted just once (N = 1, see below). KeePass ...


-1

A good encryption method like AES or RSA is more than enough. Nothing is 100% secure, but using RSA-1024 or RSA-2048 should be enough.


3

As @CodesInChaos comments, an encrypted database, if done properly, will be at least as strong against brute-force attacks as a hash value. From that point of view, the hash-based method is not more secure. There are details, though, depending on the attack model: With the local database of passwords, you can use random site-specific passwords. If one site ...


0

I'll suggest Password Safe as I think it addresses all of your points. Multi-platform. There are implementations of the software which are compatible with each other and run on Windows/Linux/Mac/iOS/Android. I generally use Password Gorilla to keep the same client on multiple platforms. Decentralized. Yep using it with Dropbox seems to work fine for me. ...


0

1Password is a Canadian competitor of LastPass and fulfills your three requirements. It is completely decentralized. They don't get your data and they don't get your password. They simply ship an application, they don't have backend servers. You can sync your encrypted data in iCloud and/or Dropbox. It offers Windows desktop, Mac OS X and iOS version. And ...


1

Might be well worth the effort to have a look at KeePass Password Safe, an offline password manager. I use it and am very happy with it. Perhaps also check out Wuala, a cloud data storage service similar to Dropbox, OneDrive, and Google Drive. Wuala is different because it encrypts your data locally before storing it on their servers (Wuala only stores your ...


0

I think there are easier methods of hacking your passwords than to try to breach LastPass's encryption. For example keyboard logging. If you really think that your credentials are in danger or being hacked, you should use a clean linux computer. Choose a really hard password (24 characters?).


0

To me this is like saying that you don't need to bother locking your car because if someone really wanted to get in they'd just smash a window. Even if you leave your LastPass session signed-in (which is not advisable if anyone else has access to your computer), it is still stronger in several ways than using any system where the keys are stored on the disk ...


1

You are asking about how to be secure under the assumption that a malicious actor has started a process on your system (or hijacked another process with their own code) running with "user trust". On Windows, you could trigger this action yourself by -- for example -- downloading http://example.com/virus.exe and then running it voluntarily. Even if you are ...


2

I guess the only thing users can do is: Use a different, strong, randomized password for each account (aiming for ~128 bits of password entropy is a good strategy, as explained in this answer); Change the password when a website implements the OpenSSL security patch. Using a password manager makes sense. I find KeePass Password Safe pretty good.


3

Most antivirus will try to protect processes from code injection. However, this is ultimately heuristic: the only clear distinction between malicious code injection, and normal process behaviour, is at the human level: did the human user actually wanted that to happen, or not. Software in general, AV in particular, cannot fathom the intricate psychological ...


0

Your password data is exactly as safe as the encryption of your TrueCrypt volume and the quality of the TrueCrypt volume password. For example, if you have used AES and a high entropy password to encrypt your volume, its very very very safe. If you want to feel even more safe, create a random keyfile from Tools > Keyfile Generator menu when generating the ...


1

Doing this makes your data marginally less safe, since "the cloud" is just a fancy name for "someone else's computer". However, you already have implemented a good control against offline attacks in Truecrypt. And, you've gone with SpiderOak, which is one of the safest cloud providers. So the risk increase is very small. At the same time, you have also ...


0

What exactly counts as "safe" is a matter of opinion. If you are using a decent passphrase on your Password Safe file, then the risks are low. It is effectively impossible to decrypt an encrypted file without the passphrase, so it wouldn't greatly concern me that a third party has my encrypted file. You are right that someone could do differential analysis. ...


1

This sounds like a good task for Shamir's Secret Sharing, as Stephen pointed out in comments. One example of off-the-shelf software that can do this is Crypto++ (relevant docs: http://www.cryptopp.com/docs/ref/class_secret_sharing.html).


0

I recommend checking out a penetration testing specific Linux Distorts like Kali Linux / BackTrack . They have necessary tools to exploit pth attacks for vulnerable versions of Remote Desktop and other services. Read more from @ http://www.kali.org/tag/pass-the-hash-toolkit/


4

The password is padded with null bytes: extra bytes of value 0x00 are appended so that the total length is exactly 14 bytes. See this, item 4. Of course, LM hash is a very poor password hashing algorithm. Don't use it (if you have the choice).


0

There are two possibilities -- either the attacker has found the actual password, or the attacker has found a hash collision. In the former case, changing the salt is pointless, in the later case it might help. Whether it would help depends largely on whether they found the match by brute forcing the password (starting with "", and ending up with ...


0

You're smart to not trust black box security, but then that leaves software security. LUKS works, is well-regarded, and supports TRIM on SSD's. Yes, you have to enter your password when you boot the machine (when it boots your /boot, actually). Having your BIOS know your password is closer to the 'convenient' side of the spectrum than the 'secure' one. ...


1

Your information is only secure as the server it lays on and the client machine and network is secure. It's always good practise to have different passwords for different websites. Reason behind it: Let's say you have same password for everything. Let's pretend "Facebook" got compromised with some vulnerability and got your password, they would able to get ...


1

Large corporations have an information security team and they are responsible for the different security policies and practices (password policies, key management, pentesting...). There are also a lot of recognized publications with good practices in security management they tend to follow (like ISO27001/ISO27002...). About VIP people, I don't think they ...


3

Do not use the same password on multiple sites. That's number one. Second, don't use simple passwords for any site where you care about your account. To do this, you need a paper list or a password manager (e.g. KeePass, LastPass, etc). A manager is almost always the way to go.


1

... I don't think there's a perfect one-size-fits-all solution. Different solutions are best in different cases. I think password safe's are a good balance of difficult passwords/not losing them, though obviously this makes the security of your password safe critical; it may even be worth having several password safes, perhaps for different classes of ...


1

It is not as secure as it most likely should be, though there are occasional justifiable reasons for storing a password in clear-text (for example, unattended third party service access when authorization token's aren't an option). It is certainly not secure to provide the decrypted password back to the user EVER.


1

If you are concerned about them using weak passwords, I would just focus on the complexity requirements. Force them to use a 12+ character password with special characters. A list of 65 million sounds to be relatively small, are these mostly less than 8 characters? In consideration of a brute force attack, it doesn't matter if there is great entropy or ...


3

Working off of your three bullet points, I'll address KeePass. a multiplatform program / browser extension, that works just as seamlessly as LastPass Multiplatform: the official KeePass 2.25 support Windows XP through 8 plus Mono (i.e. Linux, FreeBSD, MacOS). There are a variety of ports, including KeePassDroid for Android, some for iPhone/iPad, ...


1

Could you not hide/wipe-out all secret information (personal, billing, payment) when the user resets the password? It probably won't take them very long to re-enter these. You can also restore all these when they manage to re-enter one valid payment info matching the previous ones. Never trust any information that can be socially engineered (birthday, ...


-1

A bit of background first: The reason why passwords are not stored as plain text usually is to provide defence in depth. That is, in the case of a database compromise (which is something that should obviously be prevented), it should prevent the attacker from gaining access to the original user passwords. This usually makes gaining access to the PBKDF2 ...


3

I think the main issue are the client side languages (normally JavaScript), they are relatively slow. This would often lead to fewer hashing rounds and therefore weakens security. If your client side language is fast enough, you could calculate the expensive PBKDF client side, then calculate a cheap hash on server side (SHA512 for example). To get the ...


0

Look at it from two extremes:- Server is using PBKDF properly If the server is doing PBKDF properly, it would be a useless duplication of effort and resources if you do the same thing on the client-side too. You will have to implement or use a client-side software that will run PBKDF on your password and then send that to the server, and the server will ...


1

A potential method I'm considering is to give the user a file full of random data upon account creation, and have them use that as a token for resetting their account. The only issue I can see with that, though, is that people would likely lose the file. Let the user upload this verification file and verify the hash. So a potential attacker need to know ...


1

You could encourage your users to put their passwords in a secure password storage system such as KeePass. The system requires that the hold on to something anyway, better just have them hold onto the password and not add another piece (they would have to somehow secure the token file you give them to prevent it from being stolen/intercepted). You may also ...


0

It Depends on the value of the account and Implications of Deanonomization Possible solutions Store a mobile phone number to text the unlock id. Store the hash of a email address, so that the user must prove that they know the email address before emailing the unlock id. Notes on your proposed solution: Yes you could: Force them to construct a ...



Top 50 recent answers are included