Tag Info

New answers tagged

0

It might be the . and # confusing whatever regex John is using to parse the usernames. The first two only have letters and numbers, while the third one has other symbols. You should report this to the John project, their mailing list is john-users-subscribe at lists.openwall.com


1

In addition to the technique Enos mentions, another common technique is to use hashes. For many testing requirements hashes will be sufficient. Couple of gotchas, though: If the space isn't big enough, collisions could cause problems If you have logic that does something like matching account types by the first 4 digits being 0123, then hashing will fail ...


1

The "mathematical proof" is you can choose N arbitrarily: t(bcrypt) * (2^N) >> t(sha) The final hash is all about avoiding collisions, so you're safe so long as hash >> password The salt is all about avoiding rainbow tables, so you're safe so long as (rainbow table size) * (salt) >> (attacker storage space)


1

If you must absolutely use production data in DEV, you may produce a table matching actual account IDs with random ones, then destroy or adequately protect the table after transferring data. REAL ID | FAKE ID -------------------- 0000001 | 3287638 0000002 | 5917382 etc. Beware DEV data may include other information connected to the account ...


0

Depending on where you're at, I'd say this is a great high school project. The ipsec + dnssec + pki + tls/ssl route is very much a protocol based facet of this exercise. Maybe you'd like to bring up the physical security aspect of things as well. For example you bring up the location of the endpoints as a mitigating factor. After all, fips level skiffs for ...


0

The answer (at least for my work) is IPsec host to site or host to host with PKI authentication and protection of the private keys in hardware.


1

username::DOMAIN:1122334455667788:stringof32numbersandletters:muchlargerstringofrandomnumbersandletters Username: username Domain or NTLM realm: DOMAIN Challenge: 1122334455667788 LM Hash: strongof32numbersandletters NTLM Hash: muchlargerstringofrandomnumbersandletters If you are wondering why you can't pass these hashes in the pass the hash attack, ...


3

Hashing is a one-way function. Encryption can be reversed with a key; hashes cannot. The only time you'd use hashing is if you don't care what the value of something is, you just want to check that it's equal to what the user just typed in. In particular, if you hash the email addresses, you will never be able to send mail to the addresses. Since you want to ...


0

If you were to really think about it, having multiple sites to host your downloadable content, together with the hash keys would stop most run of the mill replacement attacks. Once again the assumption is the threat model where the attacker would have to replace in situ as opposed to in transit. Even with a single source, the copies would stop anyone from ...


2

What is wanted first and foremost is a hashing algorithm that is slow. Crackers crack password hashes by running password dictionaries and other combinations of characters through the hash algorithm to see whether the computed hash matches the one stolen from a database. The slower you can make that process, the harder it will be to "reverse" your hashes ...


4

Based on a google search of your hash it's a Dahua hash.Luckily for you it looks like it has some vulnerabilities www.exploit-db.com/download/29673/ I don't know if they fixed vulnerability and I don't really know much about CCTV systems.If that fails you could try bruteforcing the hash.


0

I'd say it's more of a performance question, basically which of these database schemas involves less overhead. Either way if the DB is compromised an attacker would be able to easily find the salt for each password hash. Since a salt just protects you from pre-compute attacks, but is needed for authentication, it's difficult and not really worth the effort ...


2

It really doesn't make a bit of difference. The salt in no way needs to be kept secure. There are arguably some very minor security advantages to it remaining secret (since it would provide some protection against cracking trivial passwords), but if your security is dependent on that, then your security is broken. Additionally, the difference between ...


6

Correct. As explained in that article the torrents use the BitTorrent protocol to share Sony's stolen data. Each piece that is downloaded via a seed is linked with an index into the file, and the hash of that portion is checked and verified. However, I don't believe its this hash that they are referring to in that article. Below I'll describe the process ...


4

EDITED: My first instinctive response was DON'T EVER USE THE PASSWORD AS THE SALT VALUE. And that's still pretty much where I'm standing. However; reading your post a little more carefully, no the salt is not stored in the result from the pbkdf2 algorithm. However; the purpose of the salt is that it adds entropy (randomness) to the input data before ...


4

A “salt” which is derived from the input data is no salt at all. In other words, this is an unsalted hash function which only takes a password and an iteration count and calculates the resulting hash. If the iteration count is constant, then the same password always yields the same hash. The whole point of the salt is that it's additional input. Contrary to ...


2

Is this algorithm safe enough? Depends. What's your threat model. That question literally cannot be answered without creating a model of how determined and how resourceful your threat is. That being said, I would generally say, "no, not safe enough." If you have found that the inputs are multiplied together in the first step, that automatically starts to ...


2

Sorry, I can't "Comment", have to create an "Answer". This is what you are looking for: "Subresource Integrity" http://w3c.github.io/webappsec/specs/subresourceintegrity/ Summary: http://qnimate.com/how-to-make-browsers-verify-fetched-resources-content/ Subresource integrity is only supported by the latest browsers.


2

The answers you're looking for can be found in the Cryptsetup documentation, but to summarize: LUKS uses PBKDF2 to derive a "slot key" from your password, with a default iteration count sufficient to take one second on the computer that created the LUKS volume. This "slot key" is unrelated to the key used to encrypt your data. It is only used to decrypt a ...


0

Technically there is no reason to not use Digest MD5 with TLS, but it does not add additional security for the password within the connection between client and server. So you need to check if using Digest MD5 might decrease the security of the rest of the system. Often you want to integrate the IMAP users with the system users, that is any system user can ...


0

If you are storing medical information, the be aware that in the United States, the Health Insurance Portability and Accountability Act (HIPAA) defines an IP address as "Protected Health Information"


7

This clearly depends on the jurisdiction! In Germany, IP addresses are considered personal information! See e.g. here or here if you speak German. It says, basically, that you are allowed to store the IP only as long as you need it to provide the service! This means on a website, you have to delete it after you sent all IP packets to the destination (which ...


0

I have actually done this once upon a time to get around a truly ridiculous series of password complexity and character restrictions. It's generally a bad idea; yet it would serve them right if they got hacked partially because of their own brain-damaged password requirements.


1

You can replay or forward an NTLMv2 response but the attacks may require scenario planning and/or tool changes. There may be advanced ways of cracking the hashes that you haven't yet thought about as well. For further information on replaying, check out -- http://www.room362.com/blog/2014/05/21/effective-ntlm-slash-smb-relaying/ ...


0

As others have stated thats a block cipher. Its ok to experiment with your own ideas and techniques. It can be fun! Just don't put your experiments into production. Other people that are way smarter than you or I can probably defeat your protection. Go check out modes of operation for block ciphers, identify the mode most closely related to yours, and ...


5

First don't roll your own crypto and read DTK answer. But, I do believe that we learn by experimenting so I will answer your questions Does there already exist a similar two-way function? Yes. They are called block cipher and come with different mode of operation. The block cipher is a function that encrypt the data for 1 particular block. In your ...


2

The purpose of salting when hashing passwords is to prevent identical passwords from resulting in the same hash values. If your passwords all are, as you say, long and generated by a CSPRNG, then you will not have identical passwords in your database for different users; they will all be unique, and salting adds nothing to the security of these ...


31

So IPs can in fact be considered to be PII (or personally identifiable information) in some cases, so you're right to want to consider whether you need to protect them. Generally this doesn't mean, however, going to any additional lengths beyond how you would protect other PII, say, email addresses for example. In any case, traditional hashing is likely ...


20

No. (with possible caveats) The risk posed by storing data depends entirely on what data you collect and how you use it. If you log IP addresses only then there should be no problem. If your log contains IP addresses and names you start getting closer to the boundary, but are still probably okay in most jurisdictions. If your log contains IP addresses, ...


1

What you are doing here is in fact defining a hash function: given an encryption function Encrypt(K, M) where K is the key and M is the plaintext to encrypt, you define Hash(P) = Encrypt(P, P). So you are inventing a new cryptographic function. First, for password hashing, you don't need any old hash function, because it needs to be resistant to brute force ...


1

Some CAs will not allow two certificates with the same SubjectDN, so the new one would supersede the old one. If there is no reason to believe the previous certificate had its PrKey compromised, it does not need to be revoked prior to signing and installing the replacement. Speak to the operators of your CA, especially the personnel acting as an RA, since ...


7

Read Shannon's 1949 work. Understand diffusion and confusion. Then understand that you do not understand enough *YET* about set theory, probability and linear maths to know that you don't have enough background to design or implement an enciphering algorithm. Read Dunning-Kruger effect while you are at it, but please keep learning, so that some day you will ...


0

It's largely a matter of semantics… Crypto is about making sure the time required to break it (by guessing some value) is as large as possible. "Taking time away" means that the attacker can break your security more quickly. — That is, all crypto in actual use can be "broken" given infinite time (eg: "simply" guess a private key). If your "poor busywork" is ...


1

Yes, hashes can be used in conjunction with a shared key to authenticate a message (this kind of Hash-based Message Authentication Code is the HMAC often referred to in cryptographic protocols). Some details are here. This also provides message authentication (in your scheme, Mallory could modify T2 and Bob wouldn't know; that can't happen so easily with ...


3

The only way to be secure without TLS is a browser plugin, which needs to be downloaded... over TLS. And a browser plugin is a huge usability drawback. The reason for this is there needs to be some trusted code on the user's computer. This can be either the TLS code in the user's browser, or the plugin code.


10

What you are trying to do is impossible without a secure way of sending your files to the client, such as TLS. Your approaches of hashing the password client-side require the javascript to be securely sent to the client. Otherwise, a MITM could simply serve a script that does not hash the password, but instead send the clear text password directly to them. ...


1

The other answers are clear - use SSL however, to point out what would fail if you implemented it as described: I thought of solving it with a first hashing on client side with JavaScript and then on the server side, if I receive hashed values(in case someone deletes some JavaScript), a second hashing and store those hashed values in the user ...


46

Why are you refusing to use TLS? It works, it has a good track record (some minor exceptions aside). Refusing to use good tools without a compelling reason does not engender confidence and does not immediately suggest professionalism. Additionally, do not roll your own authentication system. That is silly, and you will make mistakes. Instead, since you ...


17

SSL/TLS certificates will be free by Q2 2015. Get the certificate here: https://letsencrypt.org/ Let's Encrypt will offer domain-validated certificates signed through IdenTrust at no charge. When this goes live, these questions should be closed, IMHO


1

Stringify the sent information in a standard way, take the SHA256 hash, sign it with the private half of the key-pair that is genned for the handset when the application is installed (the public half is sent to the server at enrollment time). Most importantly, HMAC is easy to do wrong because it is crypto and crypto is really hard to do right (even Ron ...


10

What could be other good advices, to achieve as much security as I can without using SSL? You can use TLS instead of doing anything stupid.


2

What is your threat model? If every connection is sent over SSL, you do not need to worry about anyone sniffing your communications. This is actually the strongest part of your system. Good job choosing something standard. Because SSL is ensuring nobody is listening in on your communications, we should look at the endpoints. Your UUID is basically a ...


2

The idea of using the password as key in an encryption is actually quite similar to how passwords are stored. One of the early approaches to password storage was based on using DES with the password being used as key. The salt served as plaintext and the ciphertext served as hash value. For multiple reasons that approach is considered obsolete and insecure ...


1

One way to combine password hash with a secret key is to have a separate device (i.e. HSM) which encrypts password hashes sent from auth server using a key only known by the device itself. At user login, your auth server calculates a slow hash (say, bcrypt) with proper cost setting (whatever is tolerable for the server/situation, 5ms, 20ms, 100ms?) and ...


14

The properties people are looking for when storing passwords is to make it incredible tedious and slow to try and guess the original text, but it needs to be relatively fast when doing it once in software. You also don't want two users using the same password to generate the same ciphertext. To cope with this you will need either a salt in case of hashing ...


15

Very interesting thought. But we have one problem here, regular hashes have always the same size, your hash will have different sizes depending on the input. So it can be considered less secure that a regular hash. Hash function definition: A hash function is any function that can be used to map digital data of arbitrary size to digital data of ...


0

When you are encrypting, you would need to generate a KEY from a passphrase, which would be your password in this case. You would be running your password through a key derivation function like PBKDF2 which would effectively come close to a hash. So basically IMHO it's interesting but I don't think necessary in terms of security.


0

The length of a salt follows the law of diminishing returns. At no point does a salt become less secure by being longer, but it does stop getting meaningfully more secure relatively quickly. You never "crack" a salt - what you are cracking is the hashed password, to which the salt is appended. The salt just addresses the threat of rainbow tables - ...


2

Others have commented on the proper use of salts and passwords but maybe it's useful to add a word on hash functions because your question seem to suggest a somewhat incorrect intuition of the way they work. By design, a good cryptographic hash function should not let you guess how similar the inputs were based on the hashed values themselves. Otherwise, it ...


5

The only property of a salt that is important from a security perspective is that it is globally unique. The length may impact how unique the salt can be, but is irrelevant from any other perspective. Assuming that it has a positive or negative effect on anything is to ask the salt to perform a function that it was never intended to serve. So, a salt should ...



Top 50 recent answers are included