Tag Info

Hot answers tagged

10

The normal mechanism for a password manager is to have some sort of "master key" and encrypt the data (symmetrically) with that key. The master key, in your case, being derived from the master password through proper password hashing (so it becomes, in this case, password-based key derivation). So use bcrypt or PBKDF2 to turn the user's master password into ...


5

DES is a block cipher, which means that it processes blocks of a fixed size. When you want to encrypt a message, i.e. a sequence of bits whose length is not necessarily that of a single block, you need to apply a mode of operation that applies the block cipher "properly" to encrypt and decrypt a message. The Wikipedia page has nice schematics. Each mode of ...


5

The first thing that comes to mind is that once someone knows one password, they know all past and future passwords, too. The idea behind changing them yearly is to counter that problem if someone ends up cracking the passphrase, but it also provides at least a little protection against past employees who may have had access to those passphrases, too.


4

Well, let's use proper terminology then. You don't want to encrypt passwords. You want to hash password. This is something completely different. Read this. There is a good password hashing function called "bcrypt" which is internally derived from an encryption algorithm called "Blowfish"; from which came a lot of confusion with some software platforms claim ...


4

Are TLS session keys cached in a browser? Yes, sometimes, but not as you're describing. The simplest bottom line answer for you is "Yes, sessions are cached until the browser is closed." That's not absolutely true, or true in all cases, but it's a reasonably secure belief for you to base your actions upon. when authenticating to a TLS protected ...


3

Yes, this is insecure. It might pass audit if nobody checks, but it is very insecure. In any case, your method doesn't save you a whole lot, because you still have a key management nightmare of determining which year to use for which entries (unless you are basing it off of modified date, which is a bad idea). You are going to need a more fully fledged ...


2

Your story is unclear, so I assume a few things: Alice has an Android device and a computer and Bob has an Android device and a computer. (You said "both have 2", but you mean both have 1 so in total there are 2: one for each person.) The computers are compromised, but the Android devices are not. The text file to be encrypted and sent was typed on the ...


2

The little circles are indeed XOR. The size of the blocks depend on the cipher you use, for instance AES-128 has a 128 bit block size (NOTE: the 128 in AES-128 stands for the key size, not for the block size). Note that CBC is Cipher Block Chaining, an operation mode how you use a cipher, not the cipher itself. The XOR operation is logically on the bits of ...


2

Since PBKDF2 could be use to generate as much bytes as you want/need, you can of course use it for both master password hashing and key generation. You don't even need to use different salt, just generate a n bytes hash, then generate n+m bytes, discard the first n bytes and use the other m bytes as key.


2

What you're looking for sounds like Privileged Access Management - a central database that stores administrative and other non-user credentials and allows authorized users to "check them out" for use. Such systems often will programmatically change the credentials on the target system so as to prevent re-use outside the window for which access was granted. ...


2

You are close, when the client connects, the server sends over the certificate which incorporates its public key. With this certificate the browser checks if it for the right URL, if the date is valid and check if it trusts whoever signed it (the root CA). If all this checks out, the client will generate a (symmetric) session key used to encrypt and ...


2

Your understanding is pretty much correct, except for the fact that a client normally doesn't send a public key, but generates one on the spot (slightly simplified). The reason this is fine is that the server is normally like a web server, and thus "everyone" can connect to it. If you need to authenticate clients (i.e., you want to exclude spies) then you ...


1

There's a difference between the capabilities of a "root" certificate, which can be used to sign other certificates and a "server" certificate which cannot. For an SSL proxy if you use a server certificate then the only host whose traffic could be seemlessly intercepted is the one whose Common Name is included on the server cert. The general idea with this ...


1

You don't want to encrypt passwords, because with encryption, the encryption key and the encrypted data can produce the unencrypted data. If someone gains access to your data store, they can recreate the original password. With a hash, you don't store enough info to recreate the original data. All you can do is verify that input data produces the same hash ...


1

Below blog has good intro to Windows' use of Secure Boot, Trusted Boot, and Measured Boot: http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx As to 'horrificially insecure', None of these are fully-secure, for example Intel has created Boot Guard technology to help protect system at silicon/firmware ...


1

There are actually two kinds of KDFs. One kind is designed to derive a key from high-entropy input (like another key); this can be done with a fast keyed hash like HMAC. The other kind takes a password as input. Passwords are low-entropy; they're not inherently very hard to brute-force. A good password hash thus has to be slow. In your question, you said ...



Only top voted, non community-wiki answers of a minimum length are eligible