Defeating proxy using hosts file I had somebody say that it would be possible to defeat any http proxy url blocking, "by editing the hosts file and so that some whitelisted site maps to an IP address they control, with a server set to accept any domain and would return any site specified in the query parameters."

Is this a real threat?
What can I do to protect against this?

I'm going to take a stab at answering this even though you haven't really provided enough information to be clear about how your proxy works and what it's intended to do.

I am assuming the following:

All access to the Internet is filtered through this proxy; it's either invisible on the network gateway or any program not configured to use the proxy won't be allowed through the gateway. This applies to all protocols and ports.
You are filtering on hostnames, not IP addresses.

If those are both true, then yes, the attack as described would work fine. It would be an inconvenient way to browse the web but it would totally work. If you want to block it you need to either:

Filter on IP address, not hostnames, and ensure that all IP addresses you allow are trusted sites not usable as any kind of proxy.
Inspect request destination IPs and hostnames, and ensure that they match (that is, the IP is assigned to that domain) and also that the hostname is whitelisted and no whitelisted hostname runs any kind of proxy.

If the latter is untrue - that is, you filter on IP addresses, not hostnames - then this won't work as described. However, it would still work if somebody with a whitelisted IP sets up an open proxy on that IP that reads the hostname and forwards the request accordingly (and relays the response), and your users edit their HOSTS files to point all the domain names they care about to this one IP.

If the former is untrue - that is, if there's any way, on some protocol or port or through changing the program configuration, to access the Internet without going through your proxy - then bypassing the filter is always going to be possible. People have built filter-bypass proxies (which they run on their own machines) that tunnel traffic through all kinds of things, like ICMP (the protocol used by ping and tracert/traceroute), DNS requests and responses, and so on. If you allow SSH traffic - even if you block the default SSH port - it's easy; most ssh implementations let you set up port tunneling to a remote system and then all the user needs to do is tell their browser to use a HTTP proxy on localhost, forward the proxy's port through SSH to an outside box, and run an actual proxy on that box.


Can HSTS be defeated? As I know HSTS is mainly implemented to mitigate famous sslstrip attack in which browser is forced to use ssl when connecting to particular site. And I think it also prevents user to proceed to site if there is a problem with ssl cert which the site provides. Are there anything more to know about HSTS ?

Also I read mostly superficial info about HSTS and that it can be defeated. Is this possible ? (Except the obvious way to intercept before the user connects first time and block hsts header)

Which browsers support hsts ? Can hsts data be cleared like clearing browser history and cookies?

anything more to know about HSTS ?

The two key attacks it mitigates are sslstrip and MITM attacks with self signed certificates (such as the one by the Syrian government against Facebook).  It can also help mitigate HTTPS implementation problems that could lead to firesheep style attacks.

  it can be defeated. Is this possible ?

As you stated, the major limitation of HSTS is an initial connection over HTTP which makes an sslstrip attack possible.  DNSSEC has been proposed as an answer to this, but has not yet been implemented.  Given the narrow scope of HSTS, other means of defeating it would probably rely on other attack vectors.

  Which browsers support hsts?

At time of writing, Firefox, Chrome, Safari and Opera on desktop, Firefox, Chrome and the default browser on Android, and Opera Mobile. Total 57.84% of global users according to StatCounter.

Source, and for updates:
http://caniuse.com/stricttransportsecurity

  Can hsts data be cleared like clearing browser history and cookies?

Yes.  Here's how to it for Firefox.  Like clearing browser history and cookies, this should not be accessible from javascript running on a page (and it would be a major security hole if it were).


Parameters in output of password hashing function A number of encryption functions include their tuning parameters in the output. For example, SCrypt, which I've been considering for an app I'm building, outputs in the following format:

$<version>$<params>$<salt>$<hash>

It seems to me that if an attacker didn't know these values, it'd make life harder for them... but if my app doesn't know the values, then it makes things tricky for me and my users. I understand that many implementations then go on to hash this output to obscure the parameters; I presume that there is therefore a way of doing this that doesn't weaken the overall scheme or increase the chance of collisions. However, by my understanding, if this second hashing pass is reversible, then it's of limited use because an attacker can reverse it as easily as we can and get the parameters we were trying to hide from them - and if it's not reversible, then we still have the problem of the parameters being inaccessible to us as well, so I don't see how it's that different from just cutting the parameters off. I could always have the parameters as constants in the app's code, of course, but that then relies on the quality of my code obfuscation, which is something I've never been too confident about (call it healthy paranoia). It also means I couldn't migrate users from old versions without losing their passwords and anything else I have encrypted, and setting up logic to use the old and new methods in parallel seems to me like having two doors instead of one, which feels less secure.

Do these parameters really need protecting from attackers, and if so, what's the safest way to do so?

The "parameters" need not be secret. They are not meant to be secret. It is difficult to keep them secret. So, short answer: don't bother.

On a general basis, you don't want to show the hash output to just anybody. That's why, on Linux systems, /etc/shadow is not world-readable. Similarly, you don't give a dump of your Web site database to just anybody. However, there can be occasional mishaps, in which the attacker can learn part or all of your system data. You keep password hashes, instead of just the passwords, precisely for that reason. Password hashing is a "defense in depth" thing. Separating, e.g., the salt from the hash is then a "defense in deeper depth": it makes sense only if you assume that the attacker breached through the external defenses (he could get a glimpse at your site database, e.g. with a SQL injection attack) but could not breach them totally (he somehow obtained a partial database dump, which includes the hash values but not the salts, or vice versa). This is not a very probable scenario, so it is rarely worth the effort.

See this answer for a detailed discussion (in particular the sections about "salt secrecy" and "pepper").


REST API communication between two Web Servers - VPN or https? We have two servers that will be sharing data and communicate over a REST API: our main application server will communicate with the server of our client that is managing some assets.

In short:
Given the infrastructure we are setting up, namely REST API communication between to web servers, is there any reason to prefer VPN over https? What are the main differences between the two solutions?

In more details:

From a performance point of view, is there significant difference VPN and https ?
Given that we are talking only via our API, is connecting two computers via VPN not an overkill ?
If we need to secure communications with other providers, and want to keep each one in a separate network, is https more standard ?

And around here:

here is a very good question with pretty much details about https, and answer in favor of VPN... But I am still unsure about the possibilities to grow "multi providers".

Thanks to shed a light on these areas.

The two would be equally secure assuming you do things right (TLS certificate pinning on one side, and client cert authentication), but I'd prefer the VPN as it's easier to use in the long run.

HTTPS isn't that easy to use - each HTTPS server should have a cert, the app accessing the API endpoints should take care of verifying the authenticity of the remote cert, and present its own client cert. Plus, for each request a new HTTPS connection would be established, that takes time and resources.

On the other hand, the VPN is managed by the kernel itself (I assume we're talking about IPSec) and the connection is always up. Once that's up and running, you can freely use HTTP, without the overhead of establishing a secure tunnel on each request because the IPSec tunnel is always on. As a bonus, you won't need to do anything more if you ever need to use a different (possibly insecure) protocol later on.


CBC-R Cookie Encryption I would like to start by saying I'm not looking for someone to write a script for me, or even tell me how to do so. I just want to have a good understanding as to how CBC-R works with Laravel cookies. I recently read an article(Cookie Forgery) regarding Laravel cookie forgery, decryption, and Remote Code Execution. In this article, the author was able to use CBC-R(Oracle padding attack) to encode an arbitrary serialized object, without knowing the key. The concept of exploiting unserialize functions is some what straight forward, however, the CBC-R aspect of this was not so straight forward.

My understanding of this particular vulnerability, is that the attacker is able to inject a serialized object (i.e. the encrypted cookie) by encrypting the payload using CBC-R and when decrypted, exploits the unserialize() function in the decrypt procedure of the encrypter class (Illuminate class library, part of Larvel framework). I understand this is able to happen due to non-strict operators for the mac value of the cookies. This seems to possibly still be the case with the current version of Laravel (Still Broken).

Producing the serialized object seems very straight forward, however, using CBC-R to encrypt the cookie/payload is not very clear to me. What I understand is that each cookie contains an IV, Mac, and Value. The cookies are base64 encoded, and the IV, Mac, and Value are also base64 encoded. My understanding of how CBC decryption works, is by XORing the decryption of a ciphertext block(I'm assuming this is the "value") with the previous block of ciphertext(once again, I'm assuming thats the "value" from the mac, iv, value). It quotes that "If the attacker can control or know both of the inputs into the XOR operation then they can make the output, i.e. the plaintext block, anything they want".

Reading the “CBC-R” technique presented by Duong and Rizzo to encrypt arbitrary plaintexts( Rizzo & Duong), it seems like you take your plaintext payload, break it into blocks of 32 bytes, padding with null bytes where the block is less than 32 bytes. From there I am unclear exactly how to use the padding oracle to encrypt each block.

What I am thinking (please correct me if I'm wrong), that for each block you send it to the decryption oracle (i.e. set it as the value of a cookie, not sure what to set the iv, or what to set the mac). By sending it to the decryption oracle (in the form of a cookie I assume?) it will XOR the plaintext with the last ciphertext (which also contains the key and iv that you don't know), and return the new ciphertext in the form of the "value" of the cookie returned. How do you calculate the IV for each block? Does this require errors to display whether or not padding is correct for cookies submitted? I've seen scripts like the Paddo (Paddo IOActive) script, and some other tools. None of the existing scripts seem to use cookie values, or blocks of 32 bytes.

I would appreciate if somebody with knowledge of how CBC-R works, could elaborate on how the flow of this might work. For example, send request of value containing null bytes the size of the block, takes the returned ciphertext, XOR's padded plaintext with former ciphertext, resubmits to get next ciphertext, XOR's with plaintext, etc.

These are my references:

Cookie Forgery: https://labs.mwrinfosecurity.com/blog/2014/04/11/laravel-cookie-forgery-decryption-and-rce/

Rizzo & Duong: https://www.usenix.org/legacy/events/woot10/tech/full_papers/Rizzo.pdf

Let's do it in several steps...

CBC encryption and IV

CBC encryption is a block cipher mode of operation, which is best explained with a drawing that I shamelessly plunder from the Wikipedia page, and reproduce here for ease of reading:

With CBC encryption, the block cipher is used to encrypt each block of data; however, to avoid leaking information about identical plaintext blocks (see the famous penguin picture as an illustration of why this is a problem in practice), CBC includes some "randomization" of data, by XORing each plaintext block, before encryption, with the previous encrypted block. Since the first block has no "previous encrypted block", a synthetic one must be provided; that is the IV. Decryption works in the obvious way, which is made explicit in this drawing:

Since the IV must be known to the decryption engine, it must be provided with the ciphertext. It must not be a fixed value because security of CBC relies on the IV being uniformly random, with a new one for each message.

In this case, the block cipher is Rijndael. Rijndael is the basis for AES. Specifically, when NIST called for candidate functions for their new standard (to be a successor to DES and 3DES), they wanted a block cipher working with blocks of 128 bits, and accepting keys of 128, 192 or 256 bits. The Rijndael submitters proposed more: the algorithm accepted the three key sizes, but also had variants for blocks of 128, 192 and 256 bits. Rijndael was chosen as AES (among a total of 15 candidates), with the NIST requirements, i.e. blocks of 128 bits only. AES is then a strict subset of the Rijndael family of algorithms.

The Laravel designers decided to use Rijndael as block cipher, with the largest block that Rijndael can support, i.e. 32 bytes (256 bits). Why they insisted on such large blocks is unclear, but that was probably on the assumption that "larger is better", which is scientifically unsubstantiated. For security, we need "large enough" blocks: the security of most modes begins to break down when we encrypt more than 2n/2 blocks of n bits (with a given key). With n = 128, this leaves room for about 300 millions of terabytes, which ought to be sufficient; larger blocks are unnecessary. In fact, one may even claim that Rijndael with 32-byte blocks is less secure than AES in the following sense: all the analysis performed by cryptographers over the last 15 years concentrated on the variants with 128-bit blocks (the AES proper), and the other sizes have been mostly neglected.

Note: since Laravel fixed their code, all I say here is about a past version of Laravel, from last year.

Padding

CBC can encrypt only some input message whose size is a multiple of the block size. To encrypt a sequence of bytes of arbitrary length, there must be some sort of padding: extra bytes added to reach a size that can be processed by the CBC encryption engine. However, such padding must be unambiguous enough so that the receiver knows where data stops and where padding begins. Sometimes it is sufficient to add some bytes of inconsequential value, if the inner message is self-terminated; however, in general, encryption engines aim at encrypting arbitrary sequences of bytes, whose end cannot necessarily be determined internally. The most common convention, which is used here, is called PKCS#7 padding:

At least 1, and at most b bytes are added, where b is the block size (in bytes).
When x bytes are added, all the bytes have value x.

The receiver, after decrypting, reads the last message byte, which contains x and thus unambiguously documents the actual padding length, allowing its removal. Some decryption engines (not all) will also check that all padding bytes have the same value x; others will just use the value of the last byte and ignore the rest.

There are variants. For instance, some protocols define that the value of the added bytes shall be x-1 if x bytes are added. Also, some protocols (e.g. SSL 3.0, as opposed to TLS 1.0 and later versions) explicitly state that only the last byte contains x, and the other bytes may have arbitrary contents.

Crucially, padding removal may fail. Indeed, the receiver expects the last byte to contain a value x which has a value between 1 and b; some receivers also expect all last x bytes to have value x. Here, the decryption engine applies the latter rule: it will complain if any of the last x bytes contains any value other than x. A padding oracle attack is an attack where the attacker can submit messages which are purportedly encrypted with a key K (that the attacker does not know), but really were crafted by the attacker; and the decryption engine leaks a single binary information: whether decryption yielded a correct padding or not. Typically, the receiver returns an error message, and not the same error message in two cases:

After CBC decryption, no well-formed padding was found.
After CBC decryption, well-formed padding was found, but after padding removal, the conveyed data turned out to be unreadable junk.

MAC

A Message Authentication Code is a cryptographic algorithm which aims at ensuring data integrity. It can be envisioned as a "checksum with a key". In general, when there are attackers, then there are active attackers, who can modify messages while in transit or try to send handcrafted malicious messages; hence, where encryption is required, a MAC is probably needed too.

There has been some considerable work on how encryption and a MAC shall be assembled together. Nowadays, we recommend using a mode which combines both in a single unit (e.g. GCM), but the old-style method was to glue together an encryption system (typically a block cipher in CBC mode) and a stand-alone MAC (traditionally HMAC). This glue-ing can be done in about three ways, called MAC-then-encrypt, MAC-and-encrypt, and encrypt-then-MAC. The last one is the right one; done properly, it prevents large classes of attacks, including, indeed, padding oracle attacks. See this question on the crypto.SE site for more discussion on this.

It turns out that the Laravel people used encrypt-then-MAC (that's good !) but botched it (that's bad !). In encrypt-then-MAC, the data is first encrypted, then the MAC is applied on the encrypted message. This prevents oracle padding attacks and, more generally, all "crafted message" attacks, because the MAC will be checked before decryption, thus ruthlessly killing out all such malicious messages without even letting them reach the decryption stage, let alone the padding removal stage. However, such a MAC works only if it is applied to everything that is used to decrypt, and that should include the IV.

The Laravel people forgot to include the IV in the MAC input. Their MAC (which is HMAC) is computed over the encrypted blocks only. The consequence is that the attacker can modify the IV at will, and the MAC won't see it. But modifying the IV gives a lot control over the first block of plaintext. Indeed, the decryption engine, upon receiving IV and the ciphertext blocks C1, C2,..., will computed the plaintext as:

P1 = IV xor DK(C1)
P2 = C1 xor DK(C2)
P3 = C2 xor DK(C3)
...

Since the MAC is computed over the Ci blocks, the attacker cannot modify them (this would invalidate the MAC), but he can choose the IV. If he knows the original plaintext block P1, then he can "alter" it to any other value by modifying the IV. In this case, this means that the first 32 bytes of the message can be chosen by the attacker. This is what is explained in the article from your first link. Since the Laravel cookie contents are, basically, the user ID, control over the first 32 bytes is more than enough to allow arbitrary user impersonation, which is already bad.

(Ironically, the use of overlarge 32-byte blocks actually gives more power to the attacker, so really using AES and its 16-byte blocks would have been better. However, the true weakness is the improper MAC application.)

More MAC mistakes

A second, and arguably more serious, issue in Laravel's code is that its MAC verification can essentially be disabled. This is explained in the article:

  Another problem with the MAC verification code is that the comparison is done with a non-strict operator: !=. This means that PHP will attempt type juggling prior to the actual equality check. The output of the hash_hmac() function is always a string, but if $payload['mac'] is an integer then the type coercion can make it relatively easy to forge a matching MAC. For example, if the true MAC starts with “0” or a non-numeric character then the integer zero will match, if it starts “1x” (where “x” is non-numeric) then the integer 1 will match, and so on.

var_dump('abcdefg' == 0); // true
var_dump('1abcdef' == 1); // true
var_dump('2abcdef' == 2); // true

  Since the MAC is from the result of a call to json_decode() an attacker can provide an integer. This makes it quite likely that an attacker is able to provide a ‘valid’ MAC for an arbitrary ciphertext.

So now we can assume that the attacker can modify the IV and all ciphertext blocks at will, without incurring the wrath of the MAC.

CBC-R

We now come to the juicy part. The context is the following:

There is a server, using Laravel, which has an internal secret key K that the attacker does not know.
The server uses cookies, which are encrypted with K.
When the server decrypts a cookie, it does so as explained above, and it acts as a padding oracle. Specifically, since the server uses PHP's unserialize() magic, it will respond on some alleged (but altered) cookie with one of these two conceptual messages:

There was no syntactically valid padding.
I found a proper padding, but then the decryption result was some junk of length xxx bytes.

The attacker can thus not only learn whether his message resulted in a proper padding, but also what was the exact padding length in that case.
If the server succeeds at decrypting a cookie, and found a valid padding, then the contents can actually trigger arbitrary code execution on the server. This is more unserialize() magic.

The attacker's goal is thus now to handcraft an encrypted cookie value which, when decrypted, contains a properly padded payload which runs nefarious code on the server. All of CBC-R is about exploiting the padding oracle into computing such encryption. Pay attention: this is the tricky part.

For one block:

Suppose that the attacker is given two block values T and V. These are two b-byte sequences. The attacker wants to compute a third block value U such that:

T = U xor DK(V)

Why would the attacker want to do that ? This is actually forging of an encrypted message with chosen contents. The equation above is the decryption core: if the attacker finds T, then the message consisting of IV U and encrypted block V decrypts to T. In that sense, the attacker tries to work out an encrypted version of message T.

Let's see how it works. The attacker will first send a one-block cookie to the server with some random IV and one encrypted block V; but he will force the last IV byte to have value 0x00. With high probability, the server will answer with the "bad padding" error. The attacker then tries again with the same IV, except for the last IV byte that he forces to 0x01. If that fails again, then he tries with 0x02, and so on.

Suppose that the last byte of DK(V) is 0x42. When the attacker tries a forged cookie such that the last byte of the IV is 0x43, the decryption engine will obtain a plaintext block ending with 0x42 xor 0x43, i.e. the value 0x01. Now that is a syntactically valid PKCS#7 padding. The error message from the server changes: it no longer is "bad padding" but "junk decrypted contents". The attacker sees that, and concludes that decryption found a valid padding, and thus infers that the last byte of DK(V) is 0x42.

Since we have 32-byte blocks, we number bytes from 0 to 31 within a block. The attacker has just learned that the byte 31 of DK(V) has value 0x42 (in that example). He now wishes to obtain byte 30. For that, he will send one-block cookies, still with encrypted block V; he will force byte 31 of the IV to 0x40, and set byte 30 of the IV to 0x00. Setting byte 31 of the IV to 0x40 means that, upon decryption, that 0x40 will be XORed with byte 31 of DK(V), that is known to have value 0x42. The result of that XOR will then be 0x02. The attacker then sends such one-byte cookies, setting IV byte 30 to 0x00, 0x01, 0x02... until the error message from the server switches again from "bad padding" to "junk decrypted contents". When will this happen ?

Suppose that byte 30 of DK(V) has value 0xC7. When the attacker tries one of his forged cookies such that the IV ends with 0xC5 0x40, the decryption engine will XOR that with DK(V), a value that ends with 0xC7 0x42. The XOR result will then end with 0x02 0x02, which again is a valid PKCS#7 padding (of length 2 bytes), resulting in the visible error message change. Now the attacker has obtained byte 30 of of DK(V).

Iterate. The attacker knows bytes 30 and 31 of DK(V), and tries IV values whose last two bytes are 0xC4 0x41, because these yield 0x03 0x03 upon decryption-and-XOR. The attacker cycles through the possible values for byte 29, until the 3-byte PKCS#7 padding (0x03 0x03 0x03) is reached. And so on...

That way, the attacker ends up with complete knowledge of DK(V). This requires an average of 128 requests per byte (there are 256 possible values for a byte, and the attacker will reach the right one after trying half of them on average), so 128*32 = 4096 requests for the complete block. This can take a few seconds or minutes, depending on the network speed, the processing power of the server, and the will of the attacker to remain as stealthy as possible.

When the attacker knows the complete DK(V), he just has to compute:

U = T xor DK(V)

which yields the sought after value for U.

For several blocks:

With the one-block attack described above, the attacker can now obtain an encrypted version of an arbitrary multi-block message.

Let's suppose that the attacker has a multi-block message P1, P2,... Pr. There are r blocks. That message is the payload with the PHP thingies which result into remote code execution, with proper padding already applied. The attacker wants to find C0, C1,... Cr such that a cookie consisting of:

the IV of value C0
the encrypted blocks C1 to Cr

will be decrypted by the server into P1, P2,... Pr.

The attacker proceeds right to left:

The attacker chooses a random value for Cr.
Given Cr and Pr, the attacker wants to find Cr-1 such that:

Pr = Cr-1 xor DK(Cr)

This is exactly the context of the one-block attack from the previous section, with T = Pr and V = Cr. Thus, the attacker runs the one-block attack and obtains Cr-1.
Given Cr-1 and Pr-1, the attacker wants to find Cr-2 such that:

Pr-1 = Cr-2 xor DK(Cr-1)

Again, this maps to the one-block attack, with T = Pr-1 and V = Cr-1. The one-block attack yields Cr-2.
The attacker iterates. He gets Cr-3, Cr-4, and so on, down to C0.
The attacker has his complete message, and sends it to the server, and hijacks it. Endgame.

Conclusion and notes

The core issue in the (old) Lavarel code is an improperly applied MAC. A MAC which:

is applied in the encrypt-then-MAC way;
without forgetting to also send the IV in the MAC input;
and is verified without possibility of cancelling it with some PHP type-juggling;

will effectively prevent any kind of padding oracle attack.

Lacking a good MAC, one may try to make sure that the decryption engine does not leak information about the padding. This is hard: if no padding is found, then the engine has to conjure some synthetic data so as to continue processing; but subsequent steps must not yield recognizable error messages when that "synthetic data" fails to decode. Moreover, demonstrations have been made (in lab conditions) of timing attacks in which the oracle consisted in the minute difference in processing time between the processing of a "good padding" vs a "bad padding". When the attacker is on the same LAN as the server, timing differences down to the microsecond can be measured.

The CBC-R reconstruction method works for any kind of CBC padding oracles, although there are variations depending on the exact species of padding (in particular whether the decryption engine checks that all x last bytes have the same value or not). This can be applied wherever CBC-based decryption occurs without protection of a MAC. In the case of the Laravel framework, this was for cookies, and the lack of MAC was due to both improper computations, and the creative featurism of PHP. The same kind of padding oracle attacks has been applied in other contexts; the original description, back in 2002 (by Serge Vaudenay), was on SSL records. Rizzo and Duong popularized it in 2010 by showing how it applied well on ASP.NET.

This incidentally illustrates that a Javascript demo with a Youtube video can be a powerful path to fame even when the original research was done by somebody else 8 years ago. I guess this means that we need both really smart researchers like Serge, and determinate implementers who go to the trouble of understanding the research, and then applying it to practical cases, working out the zillions of practical implementation details. Theory and experimentation are two sides of Science and both are required to make things change.


Checking a salted hash against known password? I've created a mysql dump of my users and passwords and awked them into a presentable form:

Passwords:

'6cc5db1c282daa071b0cf80982d19ec0f2e21976a4c39c0c7a3ab30f102b33e2780fd56f4d507e4873630eeb5ba1a8ad8d338bb8abcf64a513630a0dea7044db'
'1927f6acb76f53106a29015ba787e6f7c826f939a64be656a669f78515ffbb2447bee266e5f57751d98f4990f71d131bcb11575199b8e717a0ad91c381df43ca'
'dfd3b2e6478c0ca15102e74251a300abba96296662686f9eeba1f2ebbb9353ad9f91546d0c02ececd5e205c0a94e083a3f63eeec9642f69ad24fd674927c6a3d'

Salts:

'ecb2796f-e69d-4ad6-858f-832170b00b5c'
'a46a3486-79dd-428b-88a8-558303fe8dc8'
'02b6fedc-6932-4893-8725-cd4c8a191d57'

With the first entry on one corresponding to the first on the other. The password for the first entry is password. I am using sha512whirlpool as the hashing algorithm.

I want to use a utility to hash a string ("password" in this case) using that same algorithm and salting it and compare it to the hashed password. Anyone have any ideas what utility might be good for this? I was hoping to use mkpasswd, but I got an error there:

mkpasswd -m sha-512 password ecb2796f-e69d-4ad6-858f-832170b00b5c

And this is the error:

Wrong salt length: 36 bytes when 8 <= n <= 16 expected.

Was I doing something wrong here? Any advice?

Note: I've transferred the question here from stack overflow.

SHA-512 and Whirlpool are two distinct hash functions, so one has to assume that you are using one of them, not both. There is no hash function called "sha512whirlpool"; this would be a most unholy hybrid.

Cryptographic hash functions do not use salts. Password hashing functions are complicated constructions that may be built with cryptographic hash functions, or other elements. mkpasswd is a command-line interface for the C library function crypt() (which deals with password hashing and not at all with encryption, despite its name). On Linux systems, crypt() supports a number of password hashing constructions, one of them using SHA-512 repeatedly, mixing in the password and the salt at various steps. This is in no way the only password hashing construction from an underlying hash function, so there is no guarantee that the examples you have at hand really used that function.

Password hashing constructions tend to work over bytes, for both the salt and the password. But humans like to read characters. There is thus some translation between the two, and, there again, there is no universal convention. Your salts, like "ecb2796f-e69d-4ad6-858f-832170b00b5c", are reminiscent of the traditional string encoding of UUID. An UUID is a 128-bit identifier, i.e. a sequence of 16 bytes, but the character representation uses hexadecimal with a few extra dashes, for a total of 36 characters. When you invoke mkpasswd, that tool tries to convert the provided salt string not by interpreting it as an UUID in hexadecimal-with-dashes, but by mapping each character to its ASCII code, thus transforming the 36-character string into a 36-byte salt. It then chastises you for providing a 36-byte salt, while the internal function expects a salt of legnth 8 to 16 bytes only.

Since the mkpasswd command-line tool expects the salt as a "string", passing arbitrary bytes may be complicated in case you want to provide bytes that do not map to printable characters. The crypt() function itself expects a salt that consists of non-zero bytes. You may have to resort to programming...


Do the new instruction sets found on Intel's Haswell Architecture make any difference in cryptographic operations? Intel's Haswell architecture has support for several new Bit Manipulation Instructions. In Intel's own words,

  Bit manipulation instructions are useful for compressed database, hashing , large number arithmetic, and a variety of general purpose codes.

Do the new instructions found on the Haswell processor make any difference in the computation speeds of the current or pending cryptographic functions being used?

Most of these operations are "trivial": they replace combinations of two or three existing opcodes. For instance, the BLSR type of instruction is, as specified in the page you link to, equivalent to a subtraction followed by a bitwise AND. This could already be done. Extra operations don't harm, and compilers will benefit from them, and, undoubtly, some cryptographic functions will gain a few cycles through use of some of these opcodes, but there is no groundbreaking result to expect.

Among the instructions, the most interesting are the counting ones (LZCNT, TZCNT) because counting the number of leading or trailing zeros in a register of N bits has cost O(log N) when using "classic" opcodes. These operations have some use in some corner cases of computations on big integers. In particular, I think this will help for binary GCD, which is used to compute divisions in finite fields -- an important step in computations over elliptic curves. Right now, division in finite fields is so expensive (when compared with multiplication) that it is worthwhile to use projective coordinates to compute things on elliptic curves: this implies about ten times as many operations, but avoids a lot of divisions, so it adds up to net gains. A fast implementation of binary GCD might change that picture a bit. For more uses of counting operations, see this Wikipedia page.

What may really boost things up is not the new instructions, but the larger registers. AVX2 offers 256-bit registers; that's room enough to compute eight SHA-256 in parallel, just like SSE2 allows for four parallel SHA-256. Password cracking software will benefit from this... (although GPU are arguably better). There is ongoing work for defining tree hashing modes for turning a given hash function into a system which benefits from parallelism; e.g. see this article (from the Keccak, aka SHA-3, designers). NIST has expressed their will to define some standard in that respect.

Of course, it still takes some particular scenario to benefit from such CPU gains. In most uses of hashing (or encryption or whatever), the cryptography is not the bottleneck; I/O is. When you hash files, you cannot hash them faster than you can read them from the disk.


Is there any possibility that a trusted CA can perform a man in middle attack? Is there any possibility that a trusted CA can perform a man in middle attack?
Since the CA certificate is installed and trusted by the browser it will never raise a warning message. Hope my doubt will be clarified by the security experts.
Thank you

There are some news articles about existing backdoors on CAs for use by Security Agencies, but the trustworthiness of these news must be checked,

New NSA Leak Shows MITM Attacks Against Major Internet Services

There is no evidence that shows the trusted CAs use their certificates for MITM attacks, because sooner or later will be identified or disclosed and that company will be convicted quickly. So, it seems unlikely that a trusted CA does it.

There are several ways users can detect MITM attacks, even when the certificate seems to be signed by a trusted CA. There are, for example, Firefox plugins available from Certificate Patrol as well as Perspectives that can help users by alerting on “new” certificates that have not been seen before.

Network Forensic Analysis of SSL MITM Attacks


How is identity implemented? When I join an organization or create a Gmail account, I am given an identity.
What does the organization do to create my identity? Does it just create new pair of public key and private key?
I tried to search the web for documents on the implementation, but couldn't find any.
Edit:
Example service: Microsoft Azure (Azure Active Directory).
I thought account and identity were synonymous for identity and access management.
I'm not sure why I thought keys were involved. Maybe because I was thinking of users logging in to an Azure Active Directory tenant and may also log in to another tenant as guest...and the two AAD tenants have to have a way of authenticating users.

In the majority of cases, an identity is just a row in a database, typically in a table called something like "users" or "accounts". It could also be a line in a file or some XML in a document or some such too. Even if it a DB, it's not necessarily a SQL DB. It is typically some sort of structured data, though (for example, local machine Windows user identities are stored in the SAM registry hive).
It will have a primary identifier (a username or email address are common, but it could also be a phone number, SSN or other government-issued identifier, physical address, or other sufficiently-unique characteristic[s]). It will most likely have an authentication verifier (a password hash, multifactor token key, etc. are pretty common, but it could also be something more exotic like a smart card public key, TLS client certificate info, or similar). It will typically have some additional information depending on the purpose of the identity (name is common; shipping address and payment info is likely if it's a shopping site; an employer might have stuff like employee number, job title, and manager), often including stuff from the list of potential primary identifiers (almost every online identity wants at least one of phone number or email these days, even if they use something different like a username to actually identify you).
How this database is accessed and used depends on a lot of factors. It could be the back-end DB of a web app, where the DB stores all info relating to any user accounts in tables with foreign keys to the users table but nobody except the web server ever uses the DB. It could be an LDAP server, possibly for an organization's email directory or full-blown Active Directory server, where the DB itself might be in any number of formats but the data is exposed through a standardized interface with any number of clients. It might be the local users list of a PC or mobile device or similar, used directly by the OS and (often indirectly, through OS APIs) by software it runs. It might be internal to a service, but exposed to lots of clients through a proprietary protocol, perhaps in a chat system.
Relatively few identities will have encryption keys - symmetric or asymmetric - associated with them, but it does happen (mostly with systems built for, or around, end-to-end encryption). For example, Signal identities use a phone number as the identifier but a public key as an authentication verifier. An identity in a GPG keyserver obviously contains a GPG public key. It would be quite uncommon for the identity provider to generate a private key, though; typically the key pair would be generated on the client and only the public key shared with the server (in plain text), since that way the server can never know the private key.


What risks are inherent with connecting to an untrusted public key server? Thomas Pornin brought up a good point about PGP key servers in an answer to a recent question, here:

Shouldn't GPG key fetching use a secure connection?

  ...you should not trust the key server...

Key servers are, after all, just another type of service that hosts what is essentially user-generated content.  This got me to thinking then, about what security risks are inherent with receiving content from a public key server, which by its very nature cannot vouch for the content that it hosts?

The only real risk I can think of is if there happens to be a vulnerability in either the OpenPGP protocol or one of its implementations, which would allow an attacker to perform arbitrary code execution via a malformed key or signature.  Have there been such vulnerabilities?  Are there other risks involved, that I'm not thinking of?  How can these risks (if any) be mitigated?

I'm not sure if there's anything specific to OpenPGP, but the problem you describe doesn't seem specific to this context.

As far as I'm aware, the exploits that lead to arbitrary code execution (e.g. based on buffer overflows) could happen to the processing of any type of a priori untrusted data that could be processed. Whether it happens in the code that processed a malformed key or any other form of data probably doesn't matter that much in this context.

Whenever you run some code that processes some data that you don't already trust (and in a way that you trust), you want that code to be bug-free, at least free of bugs that would lead to arbitrary code execution or other security problems.
Whether the data is used later by a security mechanism is a secondary concern in this case.
(Of course you also want the implementation of the necessary signature verification to be correct. That's where it matters for security purposes.)

The same type of issue could happen with any X.509-based TLS stack, for example. You'd want the TLS stack not to allow malformed certificates let an attacker get control of your system (again, that's true of any system that process a bunch of bytes it doesn't know in advance). The correct validation and verification of the certificate that will let you trust the TLS connection established once the handshake has completed successfully is very important, but only a secondary matter, then.

I think the main difference compared to other types of data is in the difficulty of implementing this type of code correctly. The storage structures used in the context of PGP or X.509 tend to rely on ASN.1, which can be about as clear as mud in many cases. Writing bug-free code that deals with ASN.1 isn't easy (IMHO).

I think Thomas's quote ("...you should not trust the key server...") had more to do with the fact you can't trust the key server as an entity vouching for the key it serves. This is just a hosting service, as opposed to an editor/publisher/author.


Practical attacks against WPA2 Maybe a duplicate: Bruteforce on 10 characters length WPA2 password

So I am trying to get into home network security for the fun of it. More concretely, I am trying to reproduce the scenario of cracking my home router's WPA2 pass-phrase.

It was trivial to record a handshake with my AP. Now, to cracking the (already known by me) password. The password consists of two long words in Bulgarian (but spelled in Latin), with capitalized first letters, no spaces, special characters or numbers.

I found two dictionaries for such passwords in Bulgarian: one, two. Neither of the two words is in any of the dictionaries.
The password is 18 characters long. While choosing it might have been a fortunate example of "correcthorsestaple", even a 10-character password in infeasible for brute-force, according to my calculations. Note that Wikipedia seems to state otherwise.

  To protect against a brute force attack, a truly random passphrase of 13 characters (selected from the set of 95 permitted characters) is probably sufficient.
  Wikipedia

aircrack-ng: 1500 keys/second
worst_case_attempts = (lowercase(26) + uppercase(26) + numbers(10) + common_symbols(15)) ^ pass_len(10)
The result is about 80 million years.

So where do I go from here? Do I learn how to generate dictionaries according to probability distributions of user input e.g. capital letters are often the first letters? Do I learn more about the details of the protocol? Do I search for other attack types e.g. somehow attack the open ports of the AP?

WPA2 uses PBKDF2 for password hashing; it is configured with HMAC/SHA-1 and 4096 iterations. The result is a 256-bit string. Since SHA-1 offers only a 160-bit output, PBKDF2 needs to apply the iterated HMAC/SHA-1 twice, to get all 256 bits of output, so this means 8192 invocations of HMAC/SHA-1. Each invocation implies two elementary calls to SHA-1 ("elementary call" means "processing of one 512-bit block with the SHA-1 compression function"), so that's 16384 hash function invocations. Once the 256-bit password-dependent key is obtained, a few extra computations are still needed to check that key against what was observed, but that's lightweight so we ignore that cost here (that's about as expensive as a couple more SHA-1 invocations). The whole 256-bit key must be available for that check, so no shortcut here: an attacker running a dictionary attack must pay the cost of computing 16384 SHA-1 instances (plus a few extra code) per password.

An attacker with a good GPU may hope for a billion SHA-1 instances per seconds, so he might "try" 60 thousands of passwords per second -- but that's assuming that he has a good, programmable GPU, and that the software he uses is up to it. Common cracking software like Aircrack-ng will usually be CPU-only, yielding the kind of performance that you observe (1500 passwords per second).
Assuming that you can find an appropriate dictionary (which may be difficult, as you notice, when the target uses Bulgarian words), and know the construction method (as you explain: two words, with capitalization), then you can compute the number of possible passwords (with a dictionary of N words, that's N2 possible passwords) and a simple division will give you the time needed to "try them all".

Without any further information on probability distributions of password components, there is little more that you can do. This also shows that the 4096 iterations of PBKDF2 are effective at making life hard for attackers.

Now, are there any possible shortcuts ? There is a potential shortcut, which is that PBKDF2 uses a salt; it is as if there was not one PBKDF2 function, but billions of billions of distinct functions, one per salt value. IF several access points use the same salt, then attackers who try to break any of these access points may collude and share the effort, because "tried passwords" for one access point will also (somehow) apply to other access points. In WPA2, the salt for PBKDF2 is the network SSID. Thus, if several access points use the same SSID, then they transform the same password into the same key.

However, the actual messages and actual encryption key will be derived not only from the hashed password, but also nonce values which the access points and the connecting client send as part of the initial steps of the handshake (see this answer for pointers). This actually prevents precomputations from being effective. There is a generic advice about not using a "common SSID" but, in the case of WPA2, using the same SSID as many other access points does not seem to induce any extra weakness.

All of the above is about trying to find the access point password, in order to either decrypt traffic, or connect to the access point and benefit from its services (namely, "free" Internet access). No weakness in WPA2 is currently known, making password guessing the only practical break-in path.

However, if the true target is not the access point but another machine which connects to that access point, then other methods may be applicable. For instance, the attacker may setup a fake access point, advertising the same SSID, but requiring no authentication at all; it is possible (depending on the victim's operating system and configuration, and the human user's ability to "click through" warning popups) that the target machine will connect to the fake access point. At that point, the attacker must provide the "Internet access" service, but he also has a direct access to the victim's machine, allowing him to try out any remote exploit relevant to that machine. Also, this puts the attacker in ideal place to try Man-in-the-Middle attacks.


"Who the entity knows." I've Googled for weeks and can't find results A lecture slide mentioned methods of authentication, one of them being.
Who the entity knows.
But the lecturer said it was up to me to research it. I've Googled as hard as I can but to no avail :(
I can't find an example or even a reference, the best I've come up with is something to do with background checks.

A Google search for authentication "who the entity knows" returns a few hits.  Here's one PDF:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.2471&rep=rep1&type=pdf

  Fourth-Factor Authentication: Somebody You Know

  ABSTRACT
  User authentication in computing systems traditionally depends on three factors: something you have (e.g., a hard-ware token), something you are (e.g., a fingerprint), and something you know (e.g., a password). In this paper, we explore a fourth factor, the social network of the user, that is, somebody you know.

  Human authentication through mutual acquaintance is an age-old practice. In the arena of computer security, it plays roles in privilege delegation, peer-level certification, help-desk assistance, and reputation networks. As a direct means of logical authentication, though, the reliance of human being on another has little supporting scientific literature or practice.

  In this paper, we explore the notion of vouching, that is, peer-level, human-intermediated authentication for access control. We explore its use in emergency authentication, when primary authenticators like passwords or hardware tokens become unavailable. We describe a practical, prototype vouching system based on SecurID, a popular hardware authentication token. We address traditional, cryptographic security requirements, but also consider questions of social engineering and user behavior.


Securing administration network We would like to secure our administration network from advanced persistant threats and also from rogue administrators. I have already read the best practices from SANS Institute, NSA or other guides.

We have separate physical networks for administration and production and admin workstation don't have internet connection, usb ports, etc... We also have encrypted databases.

Actually, this is not preventing some rogue admin to backdoor the database server to get the key (as decryption is done on database server). We could not implement application side encryption as it's proprietary software.

I want to implement zero-access administration for sensible production servers. I would like to do so by having the servers themselves pulling administration scripts and execute them only if they are signed (pgp) by at least 2 admins (with an agent and something like a git repository). (like code review but enhanced with some crypto). With that, I think that we will obtain an administration network without any single point of failure. Someone will need at least 2 administrators accounts involved to execute code on sensible servers.

I would like to know if you have some advices for protecting our administration network from rogue administrators and APT ?

I would also like to know your opinion on this kind of administration (all scripted) and if you have already implemented something like that (or have some examples)? (ie: How NSA is doing after Snowden ?)

Is there any other good practice to protect from leakage by administrators (with the constraint of not being able to encrypt the data application side) ?

As of late, there has been a best practice in the DevOps Community:

If it's not automated, it's not secure.

Automation provides benefits for security (e.g. limited, audited access via configuration management, e.g. Puppet, Chef, SaltStack), but also for availability and ease of support.  As far as availability goes, it should be fast to roll back changes as well as QA them to detect issues.  For ease of support, it no longer relies on one-off ssh commands etc run by system administrators, instead a fix is automated and can be easily reproduced.

In these environments, remote access via SSH etc to individual servers is generally disabled.  Instead, one must use the configuration management system to push any changes -- or simply deploy a new server, depending how the DevOps stack is designed.

SELinux can also be leveraged to make it so that system administrators do not have access to actual data, only sysadmin functions.  However, this is very cumbersome to maintain and is not commonly practiced, to the best of my knowledge, outside NSA and other high-security state-backed entities.

To detect and potentially prevent data loss/leaks, a DLP solution can be invoked.  This can be installed on servers (via configuration management) and will be triggered if a sysadmin attempts to download data, etc.  These solutions are often expensive, but offer a last-line of defense against rogue staff.

Corporate policy can also address remediation efforts -- if it is made clear to the sysadmins what activities might violate corporate policy, and sanctions are made clear in the policy; this may have a strong deterrent effect against potential leakers.

In the end however, a sufficiently clever sysadmin can likely circumvent most of these protections eventually.  To cite the old aphorism, "Locks keep out honest people."  You can add as many locks as you like, if you have staff dedicated to nefarious activities it will be difficult to stop them.


Odd search engine entries A customer found about a dozen valid URLs pointing to existing customer related documents at Yahoo. These URLs were not public and certainly not searchable at the customer's site. The documents have hard to guess names like https://site/dir/hardtoguessname.pdf; according to Burp's sequencer the entropy of hardtoguessname is estimated to be more than 100 bits - that should be good enough to prevent plain guessing.

The whole affair is odd for two reasons: First, there are regulary hundreds or thousands of these documents there - why where just those few indexed? Second, these URLs were indexed only by Yahoo but neither by Google nor by Bing.

I don't think that those URLs were indexed by ordinary crawling. Is it possible that a user could by chance got those URLs indexed, say, by using the Yahoo tool bar or by using Yahoo mail?

Using a hard to guess name is in no way a proper method to prevent search engine indexing.  While it may sometimes work, it is the least reliable and effective way to do it.

You should instead use the officially supported method which is placing a robots.txt file in your web root detailing which files and directories should be indexed.  This is supported by all major search engines including Google, Bing, Yahoo, AOL, etc.

The syntax is pretty straight-forward.  A simple example to prevent indexing the private directory is:

User-agent: *
Disallow: /private/

See the relevant Wikipedia page on robots.txt for more details.

Note that private documents should not be accessible directly either way.  Your website should use some form of authentication system to control what the user may access and private information or documents should not be accessible from inside the web root.


How do Access Points manage attempted Passwords? How do Access Points check whether the provided password (given by the device wishing to authenticate) is actually the correct password of the Access Point?

If a user attempts to join a secured network (whether that's WEP/WPA/WPA2) with a password, I assume that password is somehow sent to the Access Point. I have no questions about information encryption & transmission over Wi-Fi. My questions is, do the Access Points finally have the attempted password in plaintext and then see if it matches with the one in their system or what?

If that's the case, isn't every Access Point able to capture every attempted password and output them all into a .txt file?

No, the actual password isn't logged because the four-way handshake ensures that the password is never sent over open air, as this Wikipedia entry explains:

  The four-way handshake is designed so that the access point (or authenticator) and wireless client (or supplicant) can independently prove to each other that they know the PSK/PMK, without ever disclosing the key. Instead of disclosing the key, the access point & client each encrypt messages to each other—that can only be decrypted by using the PMK that they already share—and if decryption of the messages was successful, this proves knowledge of the PMK. The four-way handshake is critical for protection of the PMK from malicious access points—for example, an attacker's SSID impersonating a real access point—so that the client never has to tell the access point its PMK.

You can, however, capture that an attempt was made using Wireshark, which is explained in the WPA Packet Capture Explained tutorial:

  This is quick and dirty explanation of two sample WPA capture files. The first file (wpa.full.cap) is a capture of a successful wireless client WPA connection to an access point. The second file (wpa.bad.key.cap) is a capture of a wireless client attempting to use the wrong passphrase to connect to the AP.

Updating to include Steffen Ullrich's response concerning WEP:

  WEP is also using a challenge response authentication were the transport is not actually transferred and thus cannot captured by a rouge AP, see wikipedia


Is it possible to wrap and export RSA private key in FIPS 140-2 Level 3 compliant hardware? I would like to do the following on FIPS 140-3 Level 3 certified cryptographic token using PKCS#11:

Generate RSA key pair on token
Import AES key from multiple components
Wrap and export RSA private key with AES key (PKCS#8) into file

I am trying to do it with a few FIPS 140-2 Level 3 cryptographic token with no success. I am getting CKR_DEVICE_ERROR.

So I am asking if it is possible to do that? Does the compliance of FIPS 140-2 Level 3 allow to wrap and export private key from token? Or it is just the matter of implementation of PKCS#11?

FIPS 140-2 does not explicitly forbid key export; what it says is that the module shall prevent unauthorized disclosure; it furthermore states that when a private key is exported from a module, it shall be done with encryption. The important word is "unauthorized": simply encrypting with an AES key is not enough; that key must also be such that it is known only to "authorized" systems or people, and this depends on a lot of other parts of FIPS 140-2. Basically, you cannot export a private key "generically" simply by virtue of having employed encryption; it must be part of some documented procedure that itself complies with the roles and constraints defined in FIPS 140-2, and has been evaluated as part of the process that allowed the module to be "certified FIPS 140-2 level 3".

To make the story short:

Some modules will never allow a private key to be exported, regardless of encryption.
Some modules will allow a private key to be exported only if, at key generation time, it was tagged as "extractable" (see the PKCS#11 "CKA_EXTRACTABLE" attribute).
Some modules will allow a private key to be exported but only as part of a fully-specified procedure that is covered by FIPS 140-2 level 3; in practice, this happens only for moving keys between two equally 140-2 compliant hardware modules.

It is very improbable that a certified FIPS 140-2 level 3 module allows unbounded private key export, only protected with an externally provided AES key, and is still FIPS 140-2 level 3.


Can the recipient of my emails know my IP address? When I send out emails using Gmail, is my IP address being recorded? Can the recipient of my Gmail message know my IP address and thus infer where I am located?

Send yourself an email (at a non-gmail email address) via gmail and read the "full header" or "message source", especially "X-Originating-IP".

Compare this with your own external IP address (google [my ip is]).

The header of an email which I sent from my own gmail address to my own gmail address ("Show Original") did not contain an originating IP address, or any IP address except a reserved address in the 10.x.x.x range (in other words no IP address that would be identifiable as mine).

Then, I sent an email from my gmail address to myself at another email provider. The header of this email had an X-Originating-IP address which resolves to Google, Inc. It contained several IP addresses, none of which were identifiable as mine.

In appropriate cases a subpoena, search warrant or other lawful process directed to Google, Inc. would, of course, unmask your IP address and reveal your general location (and more legal process would force your ISP to reveal the IP address subscriber's name and address).

Your IP address was recorded by Google when you sent the email, and by God knows what other spooks inhabit the interwebs between you and your ISP, and between your ISP and Google, but it was not sent to your mail recipient(s).


Local samba share without authentication Locky and Co led me to make my local shares read only. Because there are only movies and series, it's not a big disadvantage of comfort. Now I created a share with read/write, only used for moving data between PCs. It's is cleared with a cronjob every night.
But is it a security issue, e g if malware can save itself there and infect other PCs?

Of course it IS A SECURITY ISSUE. Read-only is safe - regardless of protocol : FTP, NFS or CIFS/SMB. But write/alter access does means a way greater responsibility: you need at least a stream-in antivirus, autorun names ban and many other restrictions. IP restrictions does not count : everything can be hacked, remember.


NMAP usage questions I'm very, very new to cyber security. Going through some training at the moment, but I'm confused.

Right now I'm tasked with using Kali Linux to scan a Mint Linux VM help find an unauthorized server hosted on their network and find their IP address. I have some basic questions really:

1) My instructions states that the Mint Linux VM I have "has provided your Kali Linux machine with access to the same network as the vulnerable server". How do I know? Is this just stated?

2) How would I go about even starting? How do target NMAP at the Mint Linux?

Thanks

1) What that seems to be telling you is that the vulnerable server that you are looking into is on the same network as your Kali Linux machine. This means that you should be able to find it by scanning your local network.

2) To start using nmap I suggest that you run the command man nmap in your terminal and read through the information there that should give you a good idea of where to start. You can also go to https://nmap.org and read through the reference guide provided by nmap. That is the best way to learn how to use this tool. Play around with the features that come with it and read up on the things that you do not understand this will help you to gain a better understanding of using nmap and analyzing networks.


Privilege escalation using passwd file If I have a world writeable /etc/passwd file on a system, how can I escalate my privileges to root? I am currently a underprivileged user. The underlying OS is CentOS 7.2 in case you are wondering

I know that passwd file is not normally world writeable, I am doing a challenge that has the current scenario.

Any steps to exploitation will be greatly helpful

Passwords are normally stored in /etc/shadow, which is not readable by users. However, historically, they were stored in the world-readable file /etc/passwd along with all account information. For backward compatibility, if a password hash is present in the second column in /etc/passwd, it takes precedence over the one in /etc/shadow.

Historically, an empty second field in /etc/passwd means that the account has no password, i.e. anybody can log in without a password (used for guest accounts). This is sometimes disabled. If passwordless accounts are disabled, you can put the hash of a password of your choice. You can use the crypt function to generate password hashes, for example perl -le 'print crypt("foo", "aa")' to set the password to foo.

It's possible to gain root access even if you can only append to /etc/passwd and not overwrite the contents. That's because it's possible to have multiple entries for the same user, as long as they have different names — users are identified by their ID, not by their name, and the defining feature of the root account is not its name but the fact that it has user ID 0. So you can create an alternate root account by appending a line that declares an account with another name, a password of your choice and user ID 0.


OS X Firewall Block all incoming Connections Affecting Software Updates? I just bought a 2017 Macbook Pro with the latest OS (Mojave). In the OS X Mojave Security and Privacy-Firewall settings, I set Firewall to "Block all incoming connections" as I am extra cautious, but will my software (such as Chrome web browser, Firefox, etc.) still get new updates?  For example, will my Firefox browser still get the latest software updates or will I have to manually check for software updates because the firewall is blocking all incoming connections?

Those will not be blocked. Connections initiated from the outside ('the internet') will be blocked. However, connections initiated by your Macbook (like a check for software updates or just opening a website) will be allowed by the firewall.


Can wifi network administrators see through proxy servers? I've looked at a lot of VPNs, and "what's my ip address" sites confirm that outsiders can't tell where I really am when I'm using them, but I haven't been able to get my own WiFi yet, so I don't know what privileges they have. Can they tell that a proxy server is being used by their network, even if the person using it is obscured?

Yes, and you may not be as obscured as you think. They can't tell what you're saying to a VPN server (because it's encrypted), including what sites you're accessing via the VPN, but they can tell that you are connecting to that VPN server. In networks where you have to register your device to your name somehow (e.g. many university networks), they can also tell that it's you (or someone impersonating you) who is connecting to the VPN.

For an example: I have laptop A, an account on VPN server B. I want to say "hello" to site C.

If I talk directly to site C, a network administrator can see "A said 'hello' to C".
If I talk directly to site C over an encrypted connection (e.g. over SSL), a network admin sees "A said 'oewqhfch' to C" (where 'oewqhfch' is 'hello', but encrypted; the network admin can't decrypt it)
If I use B as a simple unencrypted proxy to talk to C (i.e. I'm not encrypting what I say to B), the admin sees "A said 'Tell C "hello" and send me C's response' to B"
If I use B as an unencrypted proxy but encrypted my communication to C, the admin would see "A said 'Tell C "oqewqer" and send me the response' to B" (this is uncommon)
If I use B as a VPN (encrypted connection to B), the admin sees "A said 'ewqrvqfqjpocn' to B". B then decrypts that to see that A asked it to "Tell C 'hello' and send me the response", but the administrator of A's network doesn't know that A said that.

So, a VPN gives the benefit that everything you're doing on the VPN is hidden from the administrator of your network; the idea is to make it as though you were directly connected to the VPN provider's network. But your network administrator still sees that you're talking to the VPN server, because they have to route your packets to and from that server.


Does adding dictionary words to passwords weaken them? This might sound like a stupid question, but hear me out. If I'm encrypting my financial information and sensitive data via a program like TrueCrypt, the strength of the password is going to matter a great deal.

The common advice is not to use dictionary words. I understand that. But what happens if I use common words on top of an already strong password/passphrase? My theory is that it adds complexity to the password by adding to its length. But I also remember a windows program that used to crack windows passwords by finding dictionary words within the larger password. So I'm not sure if I'm helping or doing harm by adding common words to a password.

Password A: ,74{x4K79*ER2R[=}@PR

Password B: ,74{x4K79*ER2R[=}@PRCorrectHorseBatteryStaple

Which of the two is stronger theoretically and in the real world?

If it matters, suppose I plan to encrypt my data with cascade AES-Twofish-Serpent encryption with Whirpool hashing.

Thank you in advance.

There's no problem with dictionary words to make passphrases; its a very good method of making a high-entropy password that you can actually remember. I recommend using four random words as a bear minimum; I typically use 6-10 diceware for to encrypt my ssh keys and encrypted password lists (about 80-128 bits of entropy if out of a ~7000 word dictionary or 100-166 bits with a ~100000 word dictionary).

If your password above was actually randomly generated from a set of 80 symbols and was 21 chars long it would have had an entropy ~132 bits.*

Yes, its well-known that you shouldn't use just a dictionary word (or two or three) with only minor modifications (capitalizing a letter or two; adding a number or random character at the end), as that will create low entropy passwords.

Your biggest worries with passwords are (a) password reuse (never share the same passwords with different entities), (b) passwords being logged or forced out of you (don't use passwords on systems where you may be keylogged), and (c) using very low entropy passwords (e.g., using a dictionary word with a couple numbers at the end).  I recommend using a password-management system like keepassx shared among your trusted computers in encrypted form, with a unique randomly generated password for each specific application you use; and encrypt that password list with a high entropy passphrase.

*As a digression, this specific password doesn't appear to have been randomly generated.  My guess was typed on a keyboard to generate it as two very unlikely patterns happened in the data:  18 of the 21 chars (everything but , K and x) came from the top two lines of the keyboard (keys from the bottom rows should have occurred about half the time),  and there was only one lowercase letter (should have occurred about 1/3 of the time).  For a truly random password these types of rare events (or worse; e.g., zero lowercase letters; or less than three chars from the bottom rows) should have happened only 0.07% of the time and 0.3% of the time respectively.  Granted you have to slightly discount that there are many tests to be applied (e.g., only left side of keyboard; etc).  Generating a non-random password potentially reduces the entropy significantly if the attacker can exploit it.


Leaking details about the user in web application Imagine a web application, which is used for getting og Open Graph tags from url. User can submit a form, which has single url input. Server opens the url in a headless browser, get og:title, og:description and og:image values and sends it to client.

I was told that if og:image is not cached on server, linking the image like that will leak details about the user who sees the preview.

I don't understand what details can be leaked. Can anybody explain this issue a bit?

It is a form of SSRF or CSRF (depending on how it is rendered), if it is not cached, it will need to fetch the image from the URLwhen viewed.

By setting the image URL to a URL the attacker control, they can possibly obtain the victim's source IP, referer URL and more from the request received to that URL.


User login failure - valid error messages I am currently working on a web portal which allows users to login via standard authentication credentials (username, password).

However, I'm required to return appropriate error messages when the login fails:

When the email entered is incorrect, return error message saying: Invalid email.
When the email entered is correct, but the password doesn't match the error message should be Invalid password, please try again.

Now, my question is whether the first error message poses any security risk. This because, when I return an error code in my API response, an attacker can use the response code to enumerate the list of valid email IDs that are registered with my database?

If not, can you direct me to appropriate resources that elaborate on valid error messages to be shown or any protocol to be followed for such login scenarios.

Yes, email enumeration could be seen as a security risk.

An attacker now knows the email of a valid account and may leverage this to try logging in with passwords from previous breaches.

It could also be used to potentially Phish users of your service.

This isn't a terrible risk though and it can be mitigated by limiting login attempts from a single (or similar IP range). You could also track overall rate of failed logins to detect more advanced enumeration attempts.

There's a number of potential pitfalls related to authentication. OWASP has a great cheatsheet on Authentication, I always recommend it as a first step to checking all your bases are covered.


How do you get Geolocation information from the CellID field in the herrevad database from Google Mobile Services? There's a database called herrevad, that can be found in /data/data/com.google.android.gms/databases. This database contains timestamped entries about (some of the) app activity of the phone. The interesting thing is that you can get the Access Point ID (SSID/Cell ID) to which the phone was connected in different moments. The Cell ID field, however, is encoded and I have not found any documentation on how to obtain the relevant data that would allow me to get the location of the Cell. So far I have only been able to recover the MCC and MNC by base64-decoding the string contained in the field, but I cannot find the Area Code and Cell ID that would allow me to geolocate the cell (by using https://location.services.mozilla.com/, for example).

I'm wondering if any people around here has gone through this and knows how to do it.

You have to input the herrevad.fb file to a online site like cellid and they will return to you decoded entry with the exact location shown on a satellite map and you will be able to track the android location history.


Standards for physical Access Control systems Hoping to help protect an IT installation, I've been looking into physical protection systems, specifically Access Control for protected areas. The field is quite big. Are there any US or International Standards on the subject? Any implementation guidelines?

So when it comes to security standards for physical security, I would recommend looking over the Department of Defense. Here's a relatively recent posting, but if you've ever spoken with anyone in their IT, they've got literally millions invested in the R&D behind security both physical and IT. Here's a (rather dry) read on the subject. I'd specifically recommend Enclosure 4: Physical security planning.

http://www.dtic.mil/whs/directives/corres/pdf/510076m.pdf


Secure storage/retrieval of data in a database I'm doing some relatively amateur C# development for a small customer support team and working with the SalesForce API in my application. With SalesForce, login using the API requires you attach a Security Token to the password. Because my users are finicky, it's going to be necessary for (only) the Security Token to be stored in the application database so they aren't needing to enter it every time they use the application.

I'm hoping to get some advice on the best method of keeping this reasonably secure as this is my first venture into any kind of serious security. I've been doing some reading and picked up the AESThenHMAC encryption/decryption method from this post.

My thoughts on the process are as follows:

On first login to the application, the user is prompted for their username, password and security token.
The security token is encrypted using the SimpleEncryptWithPassword from above with their password as the 'password' parameter and stored in the database.
On subsequent logins, the user is prompted for their username and password, the security token is retrieved and decrypted, then the user is logged in using the SalesForce API.

My questions are:

Does this provide a reasonable level of security for the storage of the Security Token?
If not, why not and what can/should I do to improve it?
If so, which of the following is the better method of indexing the Security Token by the username in the database?

Username is Plain Text
Username is hashed
Username is encrypted in the same manner as the Security Token

Thanks in advance for any advice/help/input.

The point of CWE 257 is to force the authenticating app to evaluate passwords not by decrypting them and comparing to the plaintext, but by encrypting (or actually hashing) the plaintext again and comparing the opaque texts.  But yours is not the authenticating app; it's technically the client.  Apps have to store the passwords to back end systems all the time, there's no way around it.  Heck, even my browser stores passwords from time to time.

In addition, the attack vector detailed in CWE 257 doesn't apply here.  An admin can't actually decrypt the token without the user's password, because the password is the key.  So in my opinion don't worry about it.

Overall I think your idea is fine.  You might considering binding to the device (e.g. set a secure persistent cookie with plenty of entropy) and requiring the user to re-enter the token when switching devices.

One weakness is that the user will need to go dig up his token again if he ever changes his password; this may discourage him from changing it often enough.  Then again it sounds like your primary user base can't be bothered with things like that anyway.


Why not hashing and salting passwords? When I was implementing my webapp, I decided to hash and salt users' passwords in order to protect them, even though I knew that there will never be a lot of them ... if any. Of course, I'm not saying that my implementation is perfect and will stand on the face of potential attackers, but at least I tried.

I thought this is how things work.

But after many big names in the tech industry were hacked (Sony, Adobe, Yahoo! ...), I found out that they are not hashing passwords and if they do, they don't salt them. I even read somewhere on the news that OkCupid is storing passwords in PLAINTEXT !

I am not a security guy, but I'm sure that some of you work(ed) for these companies or ones that are as big (and as reckless). So, maybe you can answer my question :

Why does a huge company with as many users decides NOT to take necessary measures to protect them ? What am I missing ?

This is speculation, of course, but they may have implemented their original system before security was at the front of everyone's minds.

Once you've implemented a system like that, you tend to reuse it in many places, and so you build up a lot of dependencies on it. And once you have dependencies, making changes becomes very expensive. Even if they had knowledgable people telling them it was insecure, and they need to change it, the cost would likely have been higher than the perceived risk.

Until the risk is realized. Then they learned the hard way that they need to take such things very seriously.


Gmail twofactor auth on untrusted computer Let's say I log in to gmail on untrusted computer using two factor auth in Google Chrome in incognito mode.

Hypothetically some virus can read my email after this even without knowing password (.dll hijacking, non legitimate extension running in incognito) while  I am logged in.

When I try to logout it can emulate sign out but actually it will not send logout request to Google servers and cookies which has been set in incognito mode can be stored somewhere and used again.

The only way to avoid this (as I think) to log in on trusted computer and click button 'Sign out all other sessions'.

Am I correct?

If you are using two factor authentication, then any malware sniffing your password would not be able to login in future.

However, as soon as you do log into an untrusted computer, your session is exposed. Any malware with access to the session could export your whole mailbox in the time it takes you to sign out other sessions using a trusted computer. They could also do other things on your Google account such as forwarding all future mail to them using Filters, or disabling two factor authentication totally. The former would show a warning message for a few weeks when logging into the Gmail web application though.

They also might be able to lock you out of your account by changing your password. All in all it is not really safe to log into an untrusted computer using a sensitive account.


How to store encryption key securely? Say I have symmetric key which I want to store securely. One way is I will store this key on file system encrypted using user password.

Then user at windows startup will enter password which will be stored in RAM. The key will be encrypted/
decrypted using this password when needed. Hence, on the file system the key always remains encrypted using user's password.

The idea is it should not be trivial to retrieve password from RAM. So this way at least I have in "some" way protected my key right?

Now my problem is if the computer (Windows) reboots, there will be none
to enter the password.

What can I do in such situation? What options I have to store key in such situation securely? e.g. so that computer reboots are possible

You want the key recoverable upon reboot and without a user present, so proposing to encrypt it with a user password and store it in RAM goes against your requirement for a recoverable key. So, encrypting it with user password is a non-starter. Let's reject that proposal.

Instead, we will need to store it in a recoverable form (i.e. in plaintext or encrypted with a key which then needs to be stored in a recoverable form). That is, we have a recursive problem - one without end. I realize you really, really like your idea and are asking a lot of different questions in order to solve the problems you have. I think that's fantastic.

However, the problems won't go away. I refer you to the answer in this exchange sub-titled "Conceptual Problem" in which is described the concept: We cannot protect a computer from itself.

This section makes it clear that if you wish to have a standalone machine recover its own key (or credential) without human intervention, you cannot prevent its theft from allowing it to be used elsewhere.


How to use IPsec Transport mode between two gateways I have read many comparisons of IPsec Transport vs. Tunnel mode, and there is a clear understanding that when two gateways are exchanging routed traffic they should use Tunnel mode. In other words, Transport mode should be used only between two hosts (or two gateways if they are communicating between each other, not routing traffic). What I try to understand is if Transport mode can be used in a gateway-to-gateway setting, even if not recommended.

My setting is as follows:

LAN1  <->  GW1   <->  GW2  <-> LAN2

In my case I want to protect the link between GW1 and GW2 (containing IP traffic from/to LAN1 to/from LAN2). It is a direct connection, no routing involved, no NAT, nothing. All the reasons for which Tunnel mode is recommended (and Transport mode is not) do not apply to my case - I am OK to leave the IP headers unencrypted and so on. I want to spare overhead bytes, so I would like to use Transport mode even if it is not recommended in this case.

I am using Ubuntu Linux with Strongswan package and IPsec in ESP mode.

My question is: is it at all possible ?

Is there a "fundamental" reason that makes it impossible, or is it just "not recommended / not usually done / not in the Cisco manual" but doable ?

Does anybody have a configuration file that works ?

The problem is applying IPsec transparently.

The SPIs used to identify Security Associations (SA) are not globally unique, they are allocated by the receiving host, so to uniquely identify an SA in the Security Association Database (SAD) the tuple SPI, protocol (ESP or AH) and destination IP address is used.  This is also how a host processes an inbound IPsec packet, by default, it simply searches for an SAD entry with a tuple matching the data from the received packet (it's also possible to first check if the destination address is local and then do the lookup in the SAD with just the SPI and protocol, that's what section 5.2 of RFC 4301 describes).

However, in the described scenario the destination is not a single known IP address that's local to the host (as is the case in tunnel mode and host-to-host transport mode) instead it could take a whole range of values as it might be the address of any of the hosts behind the receiving gateway. So the default lookup can't be used.

What's required is either a lookup that ignores the destination address (which could potentially lead to mismatches if a host behind the gateway uses IPsec itself and it allocated the same SPI), or some kind of subnet/range match for the IP addresses.

Now as far as the Linux kernel is concerned neither of these options is available. The code that searches an SAD entry for an inbound IPsec packet (__xfrm_state_lookup) insists on matching the destination address stored in the SAD entry. So unless you modify the kernel's source code in a way that changes how the destination address is treated, you can't avoid using tunnel mode.

For single IP addresses behind each gateway there exists what's called BEET mode, which the Linux kernel (and strongSwan) supports. In this mode the packets are sent in transport mode (between the gateway addresses) but before/after processing, the addresses in the IP header are changed according to the mapping addresses (the negotiated single-address traffic selectors, see draft-nikander-esp-beet-mode for details).

Side note: There is actually a flag for SAs in the Linux kernel called XFRM_STATE_WILDRECV that does allow some wildcard address matching for IPv6 but is only used for Mobile IPv6 via a separate lookup function (to process packets with Destination Options and Type 2 Routing extension headers it seems).


DrayTek Vigor 2920 HTTPS allowed In my office we have a DrayTek Vigor 2920 router, with CSM setup to only allow certain keywords (keyword objects) to certain IP groups.
This all works fine, however we've discovered that all HTTPS websites are allowed.

i.e, http:www.facebook.com will be blocked,
but https://www.facebook.com will be allowed.

Is there any setting to stop this, I've looked through all settings?

This is happening because you have configured filters based on keywords in the URL. When accessing https://www.facebook.com, an encrypted connection is established with facebook's servers and your router cannot inspect the URL anymore.

You should try blocking facebook's IP range

  Following IP address ranges are known to be used by Facebook:

  66.220.144.0 - 66.220.159.255

  69.63.176.0 - 69.63.191.255

  69.171.224.0 - 69.171.255.255

  204.15.20.0 - 204.15.23.255

  Additional IP ranges which may be assigned to Facebook Inc.

  65.201.208.24/29

  65.204.104.128/28

  66.92.180.48/28

  66.93.78.176/29

  66.199.37.136/29

  67.200.105.48/30

  74.119.76.0/22

  173.252.64.0/18

IP list from here

UPDATE:
 If you are able to change your infrastructure, then you can consider using a web proxy or a SSL proxy as  GdD pointed out.


Do major ISPs still ignore IP spoofing? I was reading this question:

Why don't ISPs filter on source address to prevent spoofing?

and based on those answers, ISPs ignore it because of the overhead of checking for spoofing.

But that question is a bit old so I wanted to check if any development has been happening?

I just don't understand why it's so hard for ISPs to implement the first hops to check if the source IP is valid and record the given IP by the DHCP server for checking the validness of the IP? how can it be a big overhead?

For example, if someone starts spoofing a lot of IPs and does malicious activity like DDoS, will major ISPs detect it or they still don't check?

I first saw the original referenced question and answered there, but I'll copy/paste my answer here since and add some more details to your additional questions:

ISP's should implement anti-spoofing. IETF's BCP38 (written in 2000!) describes a best practice for networks to do network filtering filtering to reduce spoofing and thus prevent DDoS atacks, but unfortunately(?) there is no global authority which can force them to do so.

As others pointed out, costs of implementing it may be a reason not to do so. Lower revenues could be an argument as well for some networks: not forwarding traffic means sending lower bills to customers, so it can be a business decision not to filter. Depending on the exact infrastructure and topology, it may not be so easy as you think to filter. For example, some equipment may not support it or may only support a limited number of access lists. Also, some networks have to deal with multiple layers of NAT due to lack of publicly routeable IPv4 addresses, and some networks have dynamic customers which roam through their networks or even use multiple networks as their upstreams. There are also many networks which do not implement DHCP (contrary to what you suggested in one of your comments). All of these things can make it really quite complex to implement proper anti spoofing.

However, in the pas few years a growing number of ISP's have pledged to implement controls described in MANRS ("Mutually Agreed Norms for Routing Security
"). One of the controls mentioned there is anti-spoofing. MANRS offers networks an extensive guide on implementing anti-spoofing in various ways in all kinds of setups with all sorts of equipment. Your claim that ISP's ignore it is not entirely correct (anymore). Just as MANRS has grown, many ISP's not pledging to follow MANRS did implement anti spoofing measures since they realized they were part of the problem.

Although spoofing still offers problems, more and more networks implement controls because they do realize they need to be sure they're not part of the problem. However, I'm sure that there will always be a fair number of networks who will not follow MANRS for various reasons, and also that there is a small number of networks who are willingly not filtering as a business model (and thus attracting more and more abuse). The only way to solve that, will be for all large (tier 1/2) networks to implement strict filtering, so that it becomes harder for these malicious networks to get their spoofed traffic routed across the internet.


When can I commit an OpenSSL Certificate (.pem) to source control? That is to say, in what cases does it make sense to commit .cer files, or a stack of .cer files in a .pem, to internal source control like SVN or Git?

If it's just a list of signed public keys, I imagine that it would be fine, but is that the case when it's a file with the .pem or the .cer extension?

This guide goes over the different kinds of files associated with a .cer:

https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them

However, I'm mostly interested in a quick idea of whether it's a good idea to put it in SCM, or if that doesn't have a quick idea, at least a basis to make the decision.

This is NOT a keypair, at least, as far as I know.

I also asked a similar question about this, When can I commit a Private Key to source control?:

  In general mixing code and secret configuration (passwords, keys etc) in the same respository is a bad idea because generally a lot more people need (or at least would benefit from) access to the code than need access to any given secret. Also the common workflow with VCS systems is to create lots of copies.

Based on that answer, I guess this question would boil down to, "Is this sort of file generally a secret?" and "Do many people need access to it?"

It looks like I have found an answer to my question at serverfault.com:
Server Fault topic

  The SSL certificate file is a lock.
  The SSL certificate key file is its key.

(In retrospect, this should have been obvious to me.)


How were attackers able to login to the Apache Foundation's infrastructure over ssh with passwords? (2010) SSH passwords should not have been enabled for login over the Internet. Although the Infrastructure Team had attempted to configure the sshd daemon to disable password-based logins, having UsePAM yes set meant that password-based logins were still possible.

From: https://blogs.apache.org/infra/entry/apache_org_04_09_2010

I take this to mean that they set this in /etc/ssh/sshd_config:

PasswordAuthentication no
UsePAM yes (the default)

I found a relevant question where the answer cites the following from the sshd config file:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

So an attacker can bypass PasswordAuthentication no and PermitRootLogin without-password using ChallengeResponseAuthentication if UsePAM is enabled?
Is that what probably happened here, or am I misunderstanding what the Apache blog describes?
What is the point of disabling PasswordAuthentication or setting PermitRootLogin to without-password then? I mean, in what scenario does it make sense to use these if it can be bypassed?
Can one test if ChallengeResponseAuthentication is set on a server without valid credentials? Can external attackers tell that a server is a juicy target if they don't have credentials to try with?

My best guess is that they made a mistake/typo, with this in mind I won't touch on your specific questions.

To help my case here is a comment I ripped out from the article you linked

"You should learn more about OpenSSH sshd configuration and do not put wrong statements like "having UsePAM yes set meant that password-based logins were still possible". There is nothing wrong with UsePAM yes, but you probably did not set both PasswordAuthentication and ChallengeResponseAuthentication to no."


Would a user editable URL be subjected to client vilnerability? I am working on an android application and the company request is to be able to potentially have a user edit the API URL the app uses to be able to work with different test environments.

This immediately threw up a red flag for me as this might lead an attacker putting in some bad URL (if they knew how to enable the ability to change the API URL) and do something bad to the device.

I have no security background so I dont know if this is of any concern but I feel like this can be abused some how whether it be a device exploit or other.

I tried pushing back and saying its not a good idea but they seem fixated on having it editable and I have nothing to back me up as proof that this is a bad idea.

Should I be concerned about having going down this route?

Should I be concerned about having going down this route?

Not really.  There are so many ways for someone to submit modified URLs to your server that, if making the field non-editable in your app is your protection, then you're in deep trouble.

For example, a user could use a special tool like Postman.  A user could set up a Burp proxy to intercept and edit the requests.  A user could implement their own client in Python or some other flexible language.

The application you publish is just one entry point to your service.  Focus instead on making the service resilient to unanticipated inputs.


Websockets: Is it safe to allow tokens in url parameters? For an API, I know that passing tokens in the url has the following security implications:

They get saved in browser history
They’re probably saved in your server’s logs and memory
Users might post the link, not realizing what they’ve shared
This information will be exposed in the “referrer” header.
They’re available to browser extensions.

I found a SE answer saying that these are not a concern when it comes to the case of a websockets. I understand that browser won't cache the websocket urls in history or anywhere else since it is not explicitly passed via the address bar.In that way, browser extensions also doesn't get access to them as long as we explicitly allow the access for extensions. The chances of third point is also comparatively less.

The only thing I am concerned is the logging of websocket urls in server logs and caches. Isn't it actually applicable? Do servers such as Nginx and Apache log the websocket requests?

Is my assumptions correct for points other than this?

When Websockets layer on top of TCP and handshakes are being maintained by HTTP before switching using 101 response, it is not safe to allow tokens in the URL parameters since it gets logged in the server just like how an HTTP request would do.