Tag Info

New answers tagged

0

Some issues with this: Signup would take a long time. That would be a major deterrent for many websites. Privacy, you get a lot of information about someone and if it's not something that everyone knows then obviously it's personal. It's one thing if your password table ends up on the streets, it's another when I can find out all kinds of tidbits about ...


0

It is certainly not illegal to store or display plain text passwords in general. There are some best practices that should be considered. For example, if the website is accessible over the internet then SSL should be used anytime you are displaying a password. Even for internal only sites this is still a good idea. If passwords are being displayed, that ...


0

Theres no law regarding passwords. Only law that exists applies to personal details, but a password is not a personal detail. Since the password is often selected by the end user, under EU law this will Count as consent too, so even if someone would enter personal details as their password, it would Count as consent. Depending on what the password protects, ...


1

I've used both KeePass and LastPass, and I'll share some of the things I found helpful when deciding to use a web-based password manager. There's a paper by some folks at Berkeley who analyzed various online password managers. This link points you to that paper. LastPass fixed the bookmarklet issue: blog.lastpass.com/2014/07/a-note-from-lastpass.html/ For ...


0

Well, you said that "RSA is normally deterministic", but that's the point: RSA encryption is normally non-deterministic. By "normally" I mean "when performed as is described in the relevant standard", namely PKCS#1. Both the old ("v1.5") and the new ("OAEP") RSA encryption methods include randomness, and that is voluntary: this is precisely to prevent ...


0

You are correct that you have to introduce randomness in order to mitigate a chosen plaintext attack. I'm no cryptographer, but I note that OAEP requires a random input, and that looks sufficient to me. OAEP was invented for just this purpose.


0

Yes, Apple iOS and Mac OS X have an internal Keychain with Api access, have a look at Apple Dev doc


1

Is the same decryption key used for data on the server as locally with Lastpass? Yes, the same decryption key is used for data on the server as local data. Although if you are using a Yubikey, so you can set your local password database to be encrypted with the public identifier too. Does it give a database to anyone who asks? Not anyone. ...


0

Use a cryptographically secure random number generator to generate a random sequence. There are many available, built into different platforms. Many frameworks and languages provide wrappers to access these such as the openssl_random_pseudo_bytes function in PHP. You could generate your own. The article above suggests: A cryptographically secure hash of ...


2

I thought a bit about the answers that have been posted so far, and there's interesting promise in the idea of using a public-key algorithm. Thinking out loud, each user could have a public/private key pair (where each public key is stored on the central server alongside the databases). Public key storage on the server: +-------+------------------------+ | ...


1

For each shared database, use a random generated key for its encryption. Don't store the key as is, but store it encrypted in three copies (Alice has a key encrypted with her password, Bob has a key encrypted with his password and so on). If Alice wants to change her encryption password, first decrypt her key copy and then encrypt it with the new password; ...


1

Most random number generators just generate pseudorandom numbers. They create a series of numbers which appears random at first glance, but the numbers do follow an exact algorithm. To prevent them from generating the same series of numbers everytime they are used, they are initialized by seeding them with a start value. A good pseudorandom number generator ...


0

If you are already re-encrypting the entire database on each write, then I suppose it wouldn't be that big of a leap to maintain a separate data store for each reader (or group of readers in the same way). It might prove more efficient to keep a ledger of transactions for each reader, then also specify write permissions in the metadata for each entry ...


0

In standard techie talk, "one way encryption" means hashing. Although technically hashing is a distinct operation from encryption, they are both "cryptographic primitives" and it is common (although technically incorrect) to refer to all cryptography as encryption. Being pedantic with your colleague about this point is unlikely to win you any friends. When ...


1

I know this isn't a direct answer, but per your request in comments, I am submitting it. Instead of rolling your own protocol, take advantage of existing protocols to do what you need. Your spec describes a web-based protocol with encryption and limited access to data passed from phone to PC. This web service needs high availability and uptime. Twitter can ...


6

You are correct. Hashing is not invertible and encryption is. The security expert is talking through his hat. The "pepper" that cpast is talking about is the key of a keyed hash. In that case, there are three components in the input to the hash algorithm: the password, the salt, and the key. If the database is compromised, the salt is compromised, but ...



Top 50 recent answers are included