What are the new MDS attacks, and how can they be mitigated?

My current understanding is that the microcode update changes the
behavior of the obsolete VERW instruction so that it causes a flush of
various internal processor buffers

The new behavior of the VERW instruction is described in this article. In particular:

The VERW instruction retains the same existing functionality, i.e., it checks whether the specified segment is writable from the current privilege level.
Only the memory-operand variant of the instruction is guaranteed to overwrite the buffers exploited by MDS. The register-operand variant may or may not perform the buffer overwriting functionality.
The buffer overwriting functionality occurs regardless of the result of the segment write permission check (including an exception).

The VERW instruction execution by itself does not prevent later instructions from being executed before all of the MDS-affected buffers are overwritten. Therefore, it's necessary to place a serializing instruction (Intel calls a speculation barrier) after VERW. Consider the example from the same article:
Code region A (victim accessing secret data)
VERW m16
Code region B (victim accessing data that is not secret)
Speculation barrier (for example, LFENCE)
Code region C (the attacker can only see the data accessed in B)

Assume that these instructions are being executed on a processor with the MD_CLEAR microcode update (discussed below). The execution of A may leave some secret in-flight data on the same physical core. When VERW begins execution, B may execute before all the leaky buffers are overwritten. A barrier, such as LFENCE, need to be placed after B to ensure that C cannot access the secret data.
The VERW instruction is not supported in real mode and virtual-8086 mode because segment access permissions are not available in these modes. Therefore, in these modes, a sequence of instructions, which depends on the microarchitecture, needs to be used instead.
The following characteristics of VERW explain why Intel chose to overload that instruction with the buffer overwriting functionality (instead of any other instruction or introducing a new MSR):

VERW is microcoded, which is probably necessary for a microcode update to work.
VERW is rarely used, so the resulting performance overhead is practically insignificant on existing software.
VERW can be executed at any privilege level. In particular, it can be used in cases where the security boundaries are in user mode (e.g., SGX and sandboxes).

VERW is not perfect though. As already said above, it doesn't work in real mode and virtual-8086 mode. It also modifies the ZF flag.

CVE-2018-12130 (MFBDS) can only be partially mitigated by disabling
SMT, according to an in-depth blog post. Some information can still be
leaked through a context switch during syscalls.

There are two cases that need to be considered separately:

The attacker and the victim never run on two threads of the same physical core at the same time. This can occur when HT is disabled or when the OS scheduler decides to run the threads on different physical cores at the same time (because, for example, the threads have different physical core affinities). Either way, the threads may still run on the same logical core at different points in time. An MDS exploit can still be successful. The only way for the attacker to run on the same logical core as the one the victim runs on is when the victim switches to kernel mode (e.g., system call or hardware interrupt), and the attacker gets scheduled to run next on the same logical core. Therefore, the kernel can fully prevent the attacker from exploiting the internal CPU buffers by executing the VERW instruction before returning to user mode (to run next whatever thread is scheduled on that logical core). This also ensures that the buffers contain no memory requests from the kernel when returning to user mode. Similarly, VERW needs to be executed when switching between two virtual machines on the same logical core.
The attacker and the victim may run concurrently on the same physical core. The Linux kernel documentation on MDS mentions that HT needs to be disabled for full protection to prevent this particular situation from occurring in the first place. The Intel article on MDS, however, proposes an alternative mitigation called group scheduling. The idea here is to ensure that two threads are scheduled to run on two sibling logical cores only if they mutually trust each other. The Hyper-V hypervisor already employs group scheduling (and it has been recently updated to use VERW when switching between virtual processors that belong to different VMs). During the execution of VERW (or the alternative software sequence), the sibling logical core must be quiesced (e.g., execute HLT or PAUSE) to ensure that all the buffers get overwritten.

The aforementioned mitigations (overwriting the MDS-affected buffers when returning from the kernel or when switching between VMs, disabling HT, and group scheduling) cannot protect sandboxed applications (in a web browser) and SGX enclaves, where there is no switching between privilege levels. One possible mitigation for sandboxed apps is using processes instead. SGX enclaves are protected by the microcode update itself.
The MD_CLEAR microcode update seems to include the following changes:

New functionality to the VERW instruction as discussed above. Only the buffers that are vulnerable on each particular processor are overwritten, so the impact of VERW on performance depends on the processor.
When entering or exiting an SGX enclave, the MDS-affected buffers are overwritten. However, on the entrance to the enclave, it must be ensured that no untrusted thread runs on the sibling logical core.
When exiting system management mode (using the RSM instruction), the MDS-affected buffers are overwritten. However, on the entrance to SMM mode, the SMM software must ensure that no untrusted thread runs on the sibling logical core.
The RIDL paper in Section IX mentions that "The updated microcode also flushes these buffers when flushing the L1 cache." I think this refers to the IA32_FLUSH_CMD MSR, where setting the bit at index 0 to 1 causes the processor to writeback and invalidate the whole L1D cache. This is referred to as the L1D_FLUSH command. It also overwrites all buffers that are vulnerable to MDS.

The following processors are not vulnerable to any MDS attack, but are vulnerable to TAA:

Whiskey Lake (steppings 12 and 13 only)1.
Coffee Lake Refresh (stepping 13 only).
2nd Gen Xeon Scalable Processors (steppings 6 and 7 only).

Microcode updates that are similar to MD_CLEAR also apply to these processors to mitigate TAA. Therefore, VERW has a performance penalty on these processors as well (and it's buggy according to erratum CLX38).
For some processors, Intel has released multiple versions of the MD_CLEAR microcode update to fix bugs in earlier versions.
There are processors that are vulnerable to both MDS and TAA. These include Coffee Lake Refresh (steppings 10, 11, 12 only), Whiskey Lake (stepping 11 only), 2nd Gen Xeon Scalable Processors (stepping 5 only), and earlier down to and including Haswell. On these processors, the MDS mitigations also work for TAA. There are processors that are only vulnerable to MDS and not TAA, which include some of the those that don't support TSX.
Ice Lake, Goldmont, Goldmont Plus, Tremont processors are the only modern Intel processors that are not affected by both MDS and TAA and retain the legacy behavior of VERW.
In this Intel article, the performance impact of the microcode update and OS patch (to use the VERW instruction) appears to me to be significant (over 5%) for some benchmarks. There is also a list of FAQs at the end where Intel recommends against disabling HT, which makes sense.
Section E of the RIDL paper mentions that the authors were able to leak physical addresses from the page walking hardware of the MMU (page walks go through the LFBs). I've not seen any proposed mitigations for this attack.
Some recent processors include hardware mitigations for all of the four MDS attacks. This can be checked using the following sequence of commands:
sudo modprobe msr
sudo rdmsr -p 0 0x10A

The first command loads the msr kernel module and the second command reads the value in the IA32_ARCH_CAPABILITIES MSR. If the sixth bit (bit at index 5) is 1, the processor has hardware mitigations for all MDS attacks, and so all of the mitigations discussed above are not needed. This bit is called MDS_NO. Otherwise, the processor has no hardware mitigations for at least MSBDS, MLPDS, and MDSUM. Note that if the IA32_ARCH_CAPABILITIES MSR itself is not supported, then the processor definitely has no hardware mitigations for all MDS attacks.
For discussion on how MFBDS, MLPDS, and MDSUM work, see: About the RIDL vulnerabilities and the “replaying” of loads. For discussion on how MSBDS works, see: What are the microarchitectural details behind MSBDS (Fallout)?.

Footnotes:
1 I'm not aware of any released Whiskey Lake processors with stepping 13. This could be an error in Intel's list, or it could be that Intel decided to not release these processors.


Token-based authentication - what's a good token length?

An update for those that find this question since it ranks highly on Google.

If appears from the current PHP documentation that openssl_random_pseudo_bytes can generate a cryptographically strong string, but this is system dependent.  You need to pass in a second parameter then check the response like so:

openssl_random_pseudo_bytes( 32, $cstrong );
if ( !$cstrong ) echo 'weak!';

If $cstrong is false the string is not cryptographically strong.

http://php.net/manual/en/function.openssl-random-pseudo-bytes.php

If you're using PHP 7+ you should use random_bytes instead.

http://php.net/manual/en/function.random-bytes.php

Personally I generate tokens as follows:

$token = bin2hex( random_bytes(32) );

This generates a 256 bit string, which is a bit of future proofing.


What encryption/authentication methods to use on our VPN server?

SHA512 and AES256 would be the strongest combination of the options you provided.

SHA256 and AES128 should be sufficient, at the time of writing. If that is dedicated hardware, the computational cost benefit is probably minuscule.

If you're asking this here, you will probably make other configuration mistakes later on; it seems you didn't quite grasp the concept, especially since a hash function is not authentication and a block cipher is not encryption - from a security point of view, the block cipher and hash function mentioned above are most suited from that selection to construct those functionalities, though.


What are some secure methods of sending email from your server?

There is a difference between a mail server that sends emails and a mail server that receives emails from outside. In your case you do not need to receive emails from the outside, so the mail server does not need to listen on port 25.

It is true that sendmail has a long history of security issues and a extremely complex configuration language (there is even a macro language to make configuration simpler).

sendmail is not used on current Linux distribution anymore but there is a number of drop in replacements such as qmail, exim or postfix that will provide a compatible interface and a symlink called /usr/bin/sendmail. If that symlink is used, they will parse the common command line parameters the same way
as the original sendmail did.

On Windows you need to edit the [mail function] section of php.ini to point to an external email server. Since you are sending emails to a fix target domain, it can be the mail exchange server that is responsible to receive emails for that domain. Use host -t mx example.com to learn the name.


Can the Gmail Activity IP Address's Be Spoofed?

I would think that this would be hard, if not impossible to spoof. For a TCP session to be established the three-way handshake needs to occur, and I'm not aware of a method where a spoofed IP address is able to successfully complete this.

If the traffic claims to originate from your IP address then it's almost certainly coming from your IP address. If you didn't have 2FA enabled I'd be concerned that perhaps another computer in your network was compromised, but I would wager that there isn't anything malicious going on.

I've never experienced this error myself and I have two factor authentication enabled, so I'd say reaching out to Google to inquire is your best course of action.


How does the attacker discover our server?

The short answer is that many people are scanning everything most of the time.

Doing so was, some years back, considered impractical, but the combination of better networks, better tools better throughput, and more of the space being in use means that is no longer the case.

For example, Zmap claims on its front page:

  ZMap is capable of performing a complete scan of the IPv4 address space in under 5 minutes, approaching the theoretical limit of ten gigabit Ethernet.

Botnets tend to distribute the same sort of scan across significant numbers of nodes, to achieve a similar result: any given machine on the internet is likely to be scanned at least once a day by a determined attacker/scanner.

Once a webserver is identified on a given IP, there are all kinds of tools to test well-known paths, and tools that will try and guess at your sitemap.

In short, welcome to the internet - where obscurity is not security.

Do consider this in the context of setting up your app/services/widget - in all likelihood, things you would probably prefer to be 'secret' will not be, and defending your assets and resources is necessary.


Safe user/group for rsyslog to read application log?

The nobody user is intended to be exactly that. A generic user account that doesn't belong to anyone and isn't used to run any services. As such, having a file owned by nobody:nobody is a way to make sure that only root has access but is not owned by root.

My rule of thumb would be to create a service account to run your service. That way you have things like httpd running as httpd or apache. That way if there exists a vulnerability in your service then the damage is limited. If, for example, someone can make your website run a local command it will run as a user that can only do stuff in /var/www instead of letting them gain complete control of your system.

Syslog is an interesting one. Typically it doesn't really matter what your syslog server runs as, since it's just listening on a socket and writing out to files. If your application logs using syslog, then everything will just work out. The rsyslog engine, however, can do some more advanced features such as reading a file and then processing it.

In order for rsyslogd to read a file then it must be able to read that file. So in your situation your application's log file needs to:

Be world readable
Be owner readable by user syslog
Be group readable by group adm

Alternatively, you can let rsyslogd remain running at root. That's usually not ideal, but depending on the security posture and compensating controls the risks can be largely mitigated. In either event, some reconfiguration is going to have to happen.


How could MITM worked clearly although there is an end to end encryption in WLAN?

This is very similar to another question on SE.

The simple answer is that ARP packets aren't encrypted. If they were, ARP wouldn't work in the first place.

Quoting myself from that similar question linked above:

  Simply put, ARP poisoning works because ARP works. The only thing that
  changes is that the value of the responses sent by the attacking
  machine are faked. ARP replies are implicitly trusted, and because
  they expire, they need to be refreshed periodically. Attackers
  leverage this implicit trust to send fake responses. If the details of
  the 4WHS were needed for ARP, no one (real or attacker) would be able
  to communicate ARP replies.


What's the interest for web proxy over transparent proxy

The web proxy requires explicit configuration, which is good for making life hard for surprise devices and applications that show up on the network.  Yes, you can work around this, but it's one more step.

As well, transparent proxies have to choose between breaking the user experience pretty badly (injecting a redirect in a website for auth, for instance) and efficacy.  An explicit proxy can have rational auth mechanisms that won't ever break the websites you're going to.  They can support SSL without a man-in-the-middle cert (if wanted).  The browser, knowing that there's a proxy, can interact with it in a better way (for instance, doing DNS locally vs via the proxy), and you don't get that in a transparent proxy.


Assuming proper creation, encryption, and storage, how is a breach/leak of a hash worriesome?

What matters for a password is not its length or whether it contains "special characters", but its entropy. The entropy is a measure of "how much unknown" the password is to the attacker. Since we assume the attacker to be overwhelmingly smart, this "how much unknown" reduces to "how much random": the attacker cannot be defeated by wit, but by randomness.

A definition of entropy which is appropriate for cryptography is the following: a password contains n bits of entropy if the attacker, trying potential passwords in optimal order (starting with the most probable of potential passwords), will need an average of 2n-1 tries before hitting the right one. This definition captures non-uniform password distributions; when the password distribution is uniform (all potential passwords have the same probability of having been chosen by the user), then entropy is n bits if there are 2n potential passwords.

Entropy cannot be assessed by looking at a single or even a selection of passwords; it must be computed by analysing the password generation process (and we assume that the super-smart attacker knows everything about that process except the random choices). Elements of that generation process that involve a human brain tend to be hard to estimate, because human minds are no good at randomness and try to replace it with "tricks". For instance, many people tend to believe that "special chars" (like $, %,&, @...) are somehow "more secure" or "more random" than letters. Mathematically, this does not hold.

More on the notion of entropy and its calculation is explained in that answer.

Therefore, if you want your password to resist attackers, then you must make it so that it has entropy n bits, such that 2n-1 exceeds (preferably with some margin) the number of tries (password hashes) that the attacker is ready to make. This threshold depends on several parameters, including the attacker's patience (how long he will be ready to allocate his computing power on the task of breaking a single password) and, ultimately, his budget (which translates to the number of CPU that he will be able to use on that task). Depending on the used hash function, the individual cost of each try can be configured; see this answer for some details.

Changing your password every 30 days has an impact on this analysis only if the attacker's patience was longer than one month. In practice, this is rarely the case: if the attacker has enough budget to devote 200 computers for one full month on breaking your password, then he is probably richer than you, and this raises the question of why he would want to break through your password anyway. On the other hand, password renewal implies more memory effort on your part, so it will incite you to choose "less random" passwords, which is a problem.

Password renewal policies are a firmly entrenched notion in the business of information security; many sysadmins insist on regular renewal, and security frameworks tend to treat it as gospel. This is, however, a kind of traditional dogma that does not really resist analysis, especially in the modern world (frequent password renewal used to be effective, but that was back in the pre-computer era and in a military context, where password storage systems were weak, leaked a lot, and it was assumed that a number of passwords were under enemy control at any point). See this answer for some more food for thought.

Summary:

Don't generate passwords with your head; use a computer to get a random password. See this question for guidance.
For hashing, use a proper password hashing function (typically bcrypt) configured with a high enough iteration count (higher is better, as long as it does not make it too expensive for you to use).
All other things being equal, it is better to have more randomness in a password than to insist on a password renewal policy. I recommend that you generate a very random password, and stick to it (you can remember a high entropy password if you keep it active for a long time, and type it daily).


How does SEH based exploit bypass DEP and ASLR?

http://www.exploit-db.com/wp-content/themes/exploit/docs/17505.pdf

Using SEH to achieve exploitation defeats neither DEP nor ASLR.

In particular, DEP will mitigate execution of shellcode off the stack memory page which, ultimately, it was what an SEH based exploit is trying to achieve.

Without a non-ASLR module in the process spacing being used to locate the SEH exploits key POP POP RET, ASLR remains to further impede exploitation.

As Van Jone suggested in his comment, ROP (and an info leak for module base address discovery) are necessary for DEP and ASLR defeat.


Best way to secure a cross-platform mobile app for HIPAA compliance

It's going to depend on the details your specific situation, but I believe encryption on the client may be required in your instance.  The following sample questions are posed by the HSS Technical Safegaurds document:

Which EPHI should be encrypted and decrypted to prevent access by persons or software programs that have not been granted access rights?
What encryption and decryption mechanisms are reasonable and appropriate to implement to prevent access to EPHI by persons or software programs that have not been granted access rights?

The second question in particular is the sticky point.  If you have no way of locking down the access to the folder where the device stores the ePHI, you will need to encrypt the data.  I'm not the must familiar with some of the legal nuance as to what constitutes sufficient access control for software in this situation (i.e. maybe program B can't access the folder under regular conditions, but what if the device gets rooted.), so you're better erring on the side of caution.


Can Whatsapp be MAC spoofed if the victim's device isn't on the same local network as the hacker's device?

I have no idea where you got your information, but let's start at the very beginning citing reputable sources as we go.

This youtube video shows the process for enrolling a new device in WhatsApp. Since WhatsApp is built on the same cryptography as the Signal app -- called the Signal Protocol (source), let's assume they do the same stuff inside (Signal is open source while WhatsApp is owned by Facebook, so easier to know what's going on in Signal).

Enrollment Steps:

Provide your mobile phone number.
The server sends you an SMS with a one-time activation code.
The device creates a cryptographic public key.
The server registers this public key against your phone number in a big database.

You are now enrolled. When your friend wants to send you an encrypted message, they ask the server for the public key(s) registered to your phone number, and they can start encrypting for you.

I've never used WhatsApp, but Signal lets you link as many devices as you want to your phone number. But there is a menu to unlink devices.

Nowhere in there does it use your IP or MAC addresses, so whichever friend told you that is probably not a reliable source for tech info.

It does however assume that you are the only person who can receive SMSes at your phone number, so if you lose your SIM card, or are paranoid about nation-states, then it's possible for someone to register a second device under your phone number, and then (if it works the same as Signal) unlink your first device. So don't lose your SIM card.


How to detect the OS running on IoT device?

There is an -O option on nmap that will try to detect what OS the device is running, it is by no means perfect.  It analyzes the TCP/IP stack's behavior. https://nmap.org/

If the device has port 22 (ssh) or 23 (telnet) open you could try to log/break in using some default username and password. (IoT devices aren't meant to be secure, they're meant to be stupid, so the chance of successfully logging in is too high.)  And then run the uname command as suggested in the comment.

There are many many search engines that could have indexed a page that happens to mention which operating system the specific device is running.

If there is any open port at all, you can dig in and start looking for clues. Ex: a webserver might send the Server header which might happen to name the OS.  (Be aware that it could also be lying.)

If all above fails, it is quite likely to be running something with Linux as a kernel or a proprietary BSD clone.


Securing an API using Mutual TLS - Is checking the subject DN enough?

The design in overall is ok. The only thing I would change is to check Subject Alternative Names extension and look for suitable DNS Name name type. The problem with Subject field (apart from it is obsolete) is that subject can include only one name. This means that if client has a certificate with:
Subject: CN=example.com
SAN1: DNS=example.com
SAN2: DNS=client.example.com
<...>

it is valid for client.example.com, however you will reject it with your existing logic. When you need to validate identity, use Subject Alternative Names extension only and do not rely on Subject anymore. After all, it is deprecated by RFC5280 and CAB/Forum long ago.


Isn't HTTPS enough to prevent MITM in mobile apps? Why is SSL Pinning needed?

If you use https as protection you basically trust the whole set of authorised CA’s. Any one of them can (through trickery or by intent) issue a valid certificate for your domain.
There is also the case that there are quite a few corporations / schools that require you to install their CA root certificate (with a lot less protection than the commercial CA’s)
You also have the people that use tools like burp suite to intercept the traffic between the app and your server.
Certificate pinning protects against all these issues. It will prevent a different server from talking with your app. Whether targeted and on purpose or malicious and criminal, it’s usually a good idea to add the layer of protection that pinning the certificate will add even with the additional effort of maintaining it.
In short, certificate pinning is another layer for defence in depth, making it harder for both malicious as criminals from abusing the app and your server for any purpose other than the intended.


Not true actually, crackers these days include dictionaries, combinations of words, common replacement strategies (l33tsp34k) and classic suffixes and prefixes (e.g. "staplebattery!").
The 'correcthorsebatterystaple' or whatever it was won't work anymore as it isn't complex enough. So if you must use quotations, add some symbols between words or better yet (cliche alert) use a password manager that provides more secure passwords by default.

See this post by Bruce Schneier (already from 2014 mind you!): https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html

And this previous answer: Is "the oft-cited XKCD scheme [...] no longer good advice"?


If I'm currently on a website and disable my VPN, is my ISP or the web server immediately aware of the change or does a page refresh have to occur?

In the early days of the web, webpages were mostly static and there would be no communication between your computer and the web server unless you were actively loading a page. Today, that is no longer true. It it extremely common for webpages to maintain active connections to provide features like live updates. When you see a new email appear in Gmail without refreshing, or when you see an incoming chat message, those features are powered by active connections. This very page is likely using them to alert you to new answers. It is also common to try to automatically restore these connections when there is a network interruption.

Even if the webpage doesn't have any features that would benefit from live updates, it is possible that there are still connections established for analytics and advertising purposes.

To be safe, you should assume that when you disconnect from VPN, any pages you have open can immediately pick up on the change.


Is interpreted malware easier to detect than compiled malware?

No.

Compiled code is just translated into machine code, an attacker can alter instructions for both, compiled and interpreted. Whatever you could do with one, you can also do with the other.

Your decision for either compiled or interpreted should be dependent on what you actually want to do with your code. Compiled languages usually have a higher performance, while you can easily modify interpreted code. It is easy to implement and you can run/test it on the fly.

There should be no difference between interpreted and compiled code regarding security issues, and languages should not be categorized that way in my opinion.


Is it illegal to read an e-mail that was accidentally sent to you?

http://www.economist.com/node/18529895
"Spare us the e-mail yada-yada
Automatic e-mail footers are not just annoying. They are legally useless"

At least in the EU. And no case has ever succeeded in the US either.


Application to monitor software activities

I'd suggest that you could use Process Monitor from the sysinternals suite to do this.


Not deleting session cookies.. Is it safe?

Some browsers now provide the facility to suspend and resume a session when the browser is closed with open tabs. In my experience this retains session cookies (that is to say, cookies without an expiration date, normally expected to be deleted when the browser exits).

Further, not all sites use session cookies to identify sessions in the application - some use short-lived conventional cookies meaning that even if you close the tab before shutting down the browser, it will be possible to resume the session for such services.

Hence in both scenarios, someone with access to the browser (and user account on the client) can access the session.


Relationship between RSA, Diffie-Hellman Key Exchange, PKI and X.509?

RSA is two algorithms, one for asymmetric encryption, the other one for digital signatures. They use the same kind of keys, they share the same core operation, and they are both called "RSA".

Diffie-Hellman is a key exchange algorithm; you can view it as a kind of asymmetric encryption algorithm where you do not get to choose what you encrypt. This is fine for key exchange, where you just want to obtain an essentially random shared secret between two people. Note that most usages of RSA asymmetric encryption, in practice, are also key exchange, e.g. in SSL/TLS: the client generates a random value, encrypts it with the server's public key, and send it to the server.

PKI is a concept. It builds on the notion of certificate: a certificate is an assertion of key ownership. Basically, a certificate is an object that contains an identity (a name) and a public key, and the object is digitally signed (e.g. with RSA -- the signature algorithm -- or ECDSA). A certificate is validated by verifying this signature. The idea is that if I know the public key of whoever issued (signed) the certificate, then I can verify that signature, and thereby gain some confidence in the fact that the public key contained in the certificate really belongs to the entity designated by the identity contained in the certificate.

When you organize certificates in a way such that there is a strict hierarchy, where certificate issuers are called Certification Authorities and issue certificates to each other, with a handful of top-CA called "root CA", then that overall structure is called a Public Key Infrastructure, i.e. a PKI.

X.509 is a standard for the format and contents of certificates. X.509 is rather open about what signature algorithms will be used for signing certificates, but in practice, 99% of the time, it will be RSA.


I'm afraid this report is probably too lacking in details to provide a diagnosis.  I can't diagnose this issue for you without seeing the code.

You definitely should not disregard a static analysis warning as "mitigated risk" when you haven't done anything to mitigate it and don't understand whether the warning represents an exploitable vulnerability or not.

I suggest you start by educating yourself about SQL injection, about security Hibernate, and about this particular warning.  Most likely Fortify has online help that provides a detailed explanation about this warning; you should start by reading that.  Read the following Fortify backgrounder on SQL injection in Hibernate.
I also recommend the following articles: How is SQL injection typically stopped in a Spring/Hibernate setup,
ORM injection, and How to avoid SQL injection in Hibernate (A Hibernate Urban Legend).

Update (4/20):  I see that you updated the question to include the code.  Thanks.  The code you provided is indeed dubious, and I think it is reasonable for Fortify to complain about that code.  Looking at this code, it is not possible to verify that the query passed to createQuery() is a compile-time constant, which is why Fortify issues a warning message.

Basically, the code you show appears to be constructing a SQL query using string concatenation.  That's dangerous.  If propName can be influenced by the attacker, then you've got yourself a possible SQL injection vulnerability.  It is best to avoid constructing the SQL query in this way.

In particular, there is a myth out there that using prepared statements (or parametrized queries) is inherently immune from SQL injection.  This is true, but only if the query itself is a compile-time constant that cannot be influenced by the attacker.  If you insert untrusted data into the query itself, then using it in a prepared statement doesn't somehow magically make you safe.

So the best practice is that, when you use a prepared statement, make sure the query can be readily verified to be a compile-time constant (and cannot be influenced by the attacker).

To sum up the general rules of thumb: (1) Don't use string concatenation to build up a SQL query.  (2) When you want some dependence upon runtime values, use prepared statements to bind runtime values.  (3) Make sure the query that you use to create the prepared statement can be readily verified to be a compile-time constant.  Following these practices should help ward off SQL injection attacks.


Why do mobile operating systems not implement a way to deny permissions to an app?

Firstly, in iOS you can deny access to certain resources (when they're first requested by an App you receive a popup you can either accept or reject) and therefore Apps are designed to handle the scenario of access being rejected. You can also disable Internet access on an App by App basis, although you're not explicitly asked this ahead of time. Overall there is a significantly smaller range of permissions though.

Relating to Android, I can think of a few reasons:

A permission failure throws an exception which a developer may not necessarily catch. Most Android Apps are typically not developed with the assumption that permissions will be granted selectively.
If a bunch of Apps frequently crash or work unreliably without notice it will reflect poorly on Android in the eyes of average users who don't understand the technical aspect.
Blocking Internet would be an excellent ad-block function. If an ad-supported App such as a calculator doesn't require Internet to do its core function then users could easily disable Internet and block Ads. I imagine this is particularly untenable in the eyes of Google.
It would create a significant support burden for developers to maintain a list of permissions which are "really" required for certain functions. Users could easily think an App was buggy but actually they'd just removed a required permission. For developers having to build in prompts instructing the user that additional permissions are required would create extra complexity at every point where permissions are required.
App developers should already be applying the principle of least privilege. If an App is grasping for access to things it obviously doesn't need then it's a good sign you should be suspicious.
83% of Android users don't pay attention to permissions as they are

Things might be different if:

Android developers were told from the start to assume some permissions might not be granted
Android provided a built in prompt allowing users to enable a required permission before throwing an exception
And there was a way to treat Ads differently from other Internet traffic

Obviously if you're a power-user then App Ops might be an option for you.


What ways are there to verify a self-written protocol?

There are IT security companies which provide services like code auditing (most often along with other services like penetration testing, etc.). You contact them, describing your needs, then if this fall under their competences they will send you an estimate.


These devices you describe are also known as teen-repellents and take advantage of a well know fact that our hearing frequency range deteriorates with age, while it's not yet fully developed in pre-teen age. The most effective age range such devices could target is somewhere in the range of 12 to 24 years, and some such devices have various settings for crowd control of any age, too.

They cause high-pitched, high frequency noise in the range of roughly 17.5 kHz and up, limiting its influence to mostly teenagers. Several manufacturers exist already, and since it's not a technically challenging device to make, I suspect many may have made their own versions, too. The whole idea probably comes from research in perimeter alarms, where some use rapidly changing frequency high volume noise in a bid to disturb burglar's orientation (our inner ear).

You could test your hearing of these high frequency sounds online, for example with this YouTube clip, or a faster one here to see how much of an effect these devices would have on you. Make sure you select the highest quality setting (video quality and audio quality are coupled on YouTube), otherwise some extreme frequencies might get lost with compression.

So what is the point of these devices? Mainly, they serve as anti-loitering devices for public places where gathering of greater number of teenagers is not desirable, such as luxury departments in shopping malls, adult red district areas (not confirmed), and other places where masses of teenagers would potentially create a disturbance (rollerskating, loitering, whichever is considered as undesirable behaviour by us adults).

As you have probably already anticipated by now, they're highly controversial and have caused a public outcry in many countries that tend to respect human rights, defend and uphold civil liberties, or are otherwise concerned by too big of an influence of corporations on general population.

One such device is Mosquito Anti Loitering made by MST. The page there describes more about what it's supposed to do and where to use it (that's a job for advertisers really, so best left to them). Needless to say, they left out all the bad about it, and don't address questions such as how does it affect animals and if, in what way, is it effective (street punks might be less sensitive to these sounds simply because they probably wouldn't care so much to lose their hearing abilities and rather stand next to the loudspeakers in loud concerts - to hear it better of course, while the ones it would work better on would probably be the quiet, library goer types), if it can cause nausea or similar discomfort even to generations that wouldn't be able to hear these noises (just because it's beyond our hearing range, doesn't mean it doesn't have a real physical effect on us), or indeed, if it can be considered safe to pregnant women and their unborns.

A proper article about these devices can also be found here. So far, it seems, more money went into advertising these devices than actually determining their effect on our health (or health and change in behavioral patterns of other species, like e.g. dogs, cats, horses and birds). This is certainly one of those things we'll still need to properly address in the near future, while in the meantime their producers and advertisers will gladly exploit the fact that we didn't.

Teenagers strike back

UPDATE: I was reminded of an interesting bit of information relevant to this thread by @ThomasPornin in the comments below. Thanks Thomas! What follows is a partial transcript (full transcript available in link) from episode 6 of Dara Ó Briain's Science Club, where it was also mentioned:

  This phenomenon became very well-known, by the way, because some
  company marketed an alarm that shopkeepers could play outside their
  shops to clear teenagers from in front of the shop, because only
  teenagers could hear it. My favourite thing about it is that the
  teenagers recorded the tone and used it as a ringtone on their phone,
  because teachers can't hear it in school. So, they can actually phone
  each other in class, which I think is genius.[1]

[1] Dara Ó Briain, Dara Ó Briain's Science Club, Episode 6, 0:28:59.00 - 0:29:26.64

So there we have it, a comical cause and effect, as @SteveS also pointed out in the comments (one of the first members of IT Security by the way). I didn't link to any available online video clips, as they're of course all copyrighted and/or might not be available in all countries (e.g. BBC iPlayer). Do try to find them though, they're most interesting to watch and come with a fair bit of science & technology related situational comedy on top of factual information and personal opinions of some of the best scientists of today.


Do socks5 errors expose my real ip address when downloading torrents with qbittorrent on windows 10 and using a proxy?

The simplest way to determine if your IP is exposed while torrenting is to use a tool to do just that.
You can find many sites that do this by googling "check torrent IP", but I use this one:
http://checkmyip.torrentprivacy.com/
After following the instruction on that site, it will show your exposed torrenting IP, allowing you to determine if it's the proxy's IP or your own.


The use case you are describing is perfect for a White Listing application.  In the past I have use Savant Protection and have had good success.  Savant allows you to specify what applications are allowed to execute though either a configuration file or by "training" it.  Savant will take all of the white listed applications, calculate their hash values and stoarge location and place all of this information into an encrypted database.  Before an application is allowed to execute, savant compares the current state against the database.


It was a fun exercise for me, so +1 for the question.

The {MD5} part indicates that the string after it is an MD5 hash. As you can see by the trailing ==, that means the string has been encoded with Base64. By Base64-decoding it, you get the following in binary

00100101 11111001 11100111 10010100 00110010 00111011 01000101 00111000 10000101 11110101 00011000 00011111 00011011 01100010 01001101 00001011

By converting that binary to HEX, you get:

25 f9 e7 94 32 3b 45 38 85 f5 18 1f 1b 62 4d 0b

Remove the spaces and you get

25f9e794323b453885f5181f1b624d0b

Finally run it through an MD5 rainbow table service (I used md5rainbow.com) and you get the original text:

123456789


This feel like re-inventing the wheel. Big time. SSL should be able to fulfill the requirements (of PCI and many other secure communications needs), maintain both confidentiality and integrity + support good solid authentication quite simply and effectively without having to invent your own protocol.


Nmap scanning with and without proxychains has different behaviour

You are basically comparing access from the local machine to the local machine (i.e. fully internal to the machine) with no firewalls in between to access from some remote machine to your local machine with likely firewalls and maybe even NAT in between. It is expected that the results will be different since firewalls/NAT block the traffic.


The UI does not make this all too transparent, but no public key is exported.
You should see an invalid signature info message below the left input field.
This means, that while jwt.io was able to read your token, it was not able to verify the signature. You can, however, provide the website with your secret (depending on the algorithm, a public and private key or shared secret): with this information, it is now able to verify the signature.
A JSON Web Token consists of three parts: a header, a body and a signature.
These are highlighted in three colors by the jwt.io website.
Word of advise: never give out production level keys or tokens.


List of Top security risk/attack scenarios for android application

Your question is probably not answerable here in its current form. The entire point of the OWASP mobile security project is that there are a great many threats, of which the top ten are listed, and a large number of mitigating controls or activities.

Insecure Data Storage
Weak Server Side Controls
Insufficient Transport Layer Protection
Client Side Injection
Poor Authorization and Authentication
Improper Session Handling
Security Decisions Via Untrusted Inputs
Side Channel Data Leakage
Broken Cryptography
Sensitive Information Disclosure

If you read the page you linked to, you will see their summary of risk, and a current list of mitigating controls for each of the top ten, and this is still a work in progress so the expectation is that the community will help to build more detail in to the document.

All those ten are applicable to Android phones, so read the risk summary for each one and look at your application to see if you use any of the mitigation controls.


Aircrack-ng, Fern, and other sectools for wifi pen testing are a capture and correlate type application. If you do not need automated correlation and are simply interested in traffic capture out your own Ethernet interface you can capture with wireshark, tcpdump, netcat, ettercap, net hogs, scapy, cloudshark, packetyzer and many many more. They all have the ability to capture wifi traffic on the local interface: see this wiki for tuts on how to capture using shark for Windows:

https://wiki.wireshark.org/CaptureSetup/Loopback

This has details of how to setup capture for LAN out of local device interface and for capture self generated  (local host) non Ethernet traffic from local host. (Use this to test if you are capturing). Hope this helps.


Can I disable access to JS APIs in the browser such as highres timers?

Before the browsers get patched, you can write a user script to replace these DOM objects with dummies or delete the performance property altogether.

This is mostly a development feature and public website shouldn't need it to function anyways.

However, due to stupid "features" like NaCl/WebAssembly and WebGL, there may be many other ways to do a timing side channel attack in a browser.


Is secure to enable tools like git on shared server?

Using git exposes you to some potential risk and gives you some substantial benefits.

If your users cannot login to the server today, and if you're going to compile their code on that server, then you're likely enabling them to run code in a way they cannot today.  That's the risk.  That's probably a small real increase in risk -- you were running their code already.

This is substantially mitigated by the existence of logging and potentially accountability: the code they run has to be checked into git, where you'll be able to see what they did.

The tradeoff is probably a substantial win for security.


Quantum computer misconceptions

First, I think you misunderstand quantum computers. They are a hard and non-intiutive concept, so I don't blame you. Let me try to clear things up.

Metaphor: GPUs are exceptionally good at computations involving matrices (aka linear algebra) and therefore excel at problems that parallelize well. At any other type of problem (computing pi, for example) they are much slower than CPUs.

Quantum computers are exceptionally good at computations involving waves, and therefore excel at problems with repetitive or periodic structures. There is a surprisingly small number of things that quantum computers are good at, but it just so happens that all the public key algorithms we use today (RSA, DSA, DH, and ECC) are in this category. Generally speaking, hashes and symmetric ciphers like AES are not vulnerable to QC's.

The statement that "quantum computers are faster than binary computers" is, except for a select type of problems, wrong.

Offline Brute-force

Here the attacker has a copy of the of the hashed password(s) and is trying to guess the plaintext password(s) (aka hash pre-images). Quantum computers are not very good at breaking hashes; but if you load the hash value into the qubit register, you can use Grover's algorithm to get a sqrt(n) speedup, essentially reducing a 128-bit hash to 64 bits, a 256-bit hash to 128 bits, etc. Assuming passwords are hashed with a 256-bit hash function, you're good. So if your users chose strong passwords (aka randomly generated), then guessing is still centuries or millennia, even with a quantum computer. Assuming your users chose weak easy to guess passwords, then QC's also don't make a difference because you'll crack it in under a minute on a regular GPU rig. So quantum computers don't really make a difference for offline brute-force attacks.

Online brute-force

Here you are submitting guesses to a live login server. Since the attacker doesn't know the password hash to feed into a quantum computer, you have nothing to run Grover's on. Besides, the 5 guess-per-secand rate-limit and IP banning done by the server is the bottleneck here, not the size of your processor. So quantum computers make no difference for online brute-force attacks either.

Key-Based SSH

You specifically asked about username/password, but I'll borrow from @Trickycm's answer. If your SSH server is using RSA keys rather than passwords, then it's a different story and against a quantum adversary you get something like "weak passwords" < "RSA keys" < "32 char random passwords" (depending a bit on which symbol set you're generating passwords from, and the size of your RSA keys).


Bitdefender Antivirus SSL Cert substitution

Bitdefender is doing here a Man-in-the-Middle attack, except that it is not really an "attack" since you actually consent to it. Bitdefender impersonates you when it talks to the server, and impersonates the server when it talks to your browser. This requires Bitdefender to create on-the-fly a fake certificate for the target server; your browser is fooled by it because Bitdefender added its own CA certificate to the set of roots trusted by your browser. That CA is, really, operated by Bitdefender itself.

All of this occurs locally on your own computer. There are two SSL connections, one between your browser and the local Bitdefender process, and one between Bitdefender and the remove server. Bitdefender forwards data back and forth, and can see it all plainly, which is the point of the exercise.

The remote server is blissfully unaware of these shenanigans.


Could my pc's mac address be guessed and thereby stored by websites?

No. You should enable privacy settings for IPv6, so that you use a pseudo generated IP, and not one based on the MAC of the computer. On Windows this appears to be the default, although I have never studied IP allocation on Windows in detail with IPv6.

IPv6 can indeed increase privacy through the use of ephemeral addresses that are short-lived.

As with all technology, you need to understand it and quantify the risks.


Does Windows have a built-in password store?

Windows Credentials

Yes, they are stored hashed within files in the c:\Windows\System32\Config\ directory. You will need the SAM and system files. However, a backup of these files may be stored in the Windows repair folder at c:\Windows\Repair\. SAM contains the hashed passwords, however they are encrypted using the boot key within the system file.

If Windows is running and you need access to the locked files in the Config folder (for example you know the files in Repair are out of date), you can extract these files using regedit.

C:\>reg.exe save HKLM\SAM sam
The operation completed successfully
C:\>reg.exe save HKLM\SYSTEM sys
The operation completed successfully

An alternative is to use a tools such as Pwdump which can extract the hashes stored within the SAM/system files directly without the need to use regedit or manual decryption of the SAM using the boot key.

Windows passwords may also be cached in memory. Windows Credentials Editor can extract these values in plain text from the Windows Digest Authentication package.

C:\>wce -w
WCE v1.3beta (Windows Credentials Editor) - (c) 2010,2011,2012 Amplia Security - by Hernan Ochoa (hernan@ampliasecurity com)
Use -h for help.

test\MYDOMAIN:mypass1234
NETWORK SERVICE\WORKGROUP:test

You will need local administrator access to do all of the above, unless you can mount the partition from another machine to directly access the files in the first case.

Network Credentials

Network passwords are stored inside Windows Vault/Credential Manager:

Tools such as Windows Vault Password Decryptor can extract and decrypt these.


It all depends on what you want to do.

Answer to the first part of your post:

There are .net implementations of secure string in the following: WPF's System.Windows.Controls.PasswordBox control keeps the password as a SecureString internally (exposed as a copy through PasswordBox::SecurePassword) The System.Diagnostics.ProcessStartInfo::Password property is a SecureString and finally X509Certificate2 takes a SecureString for the password.

Answer to the second part of your post:

If you want to get more into the internals of hashing, BCrypt/BCryptPrimatives/PBKDF2 are generally considered FIPS 140-2 compliant (A Government Standard) specifically because they do carefully handle hashing and passwords on disk and in memory.

If you really want to go into the nitty gritty (And it seems like you do...) Go here: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1892.pdf

There are plenty of details about how this works in that PDF, sorry for the link, it's just too big of a subject to cover in a single post.


Rainbow tables (MD5 and SHA-1) with all 8 char combinations

It's doubtful that a rainbow table containing every combination of 8-character passwords exists, because the size of such a rainbow table would be enormous.

Assume (conservatively) that there are 80 different characters that can be used in passwords (i.e. 26 uppercase letters, 26 lowercase letters, 10 digits, and 18 symbols).  This means that there are 1.67*10^15 different combinations of 8-character passwords (80^8).  A SHA1 hash is 160 bits, or 8 bytes.  So, for each password combination, 8 bytes would need to be stored in a SHA1 rainbow table.  So, the total number of bytes that the rainbow table would consume is 1.34*10^16 (8 * 1.67*10^15).  That's over 13,000 terabytes.

You can do similar calculations to estimate how many bytes would be consumed by rainbow tables containing shorter length passwords of every combination:

8 characters: 13,421 TB
7 characters: 167 TB
6 characters: 2.1 TB
5 characters: 26 GB
4 characters: 327 MB


How should backups be tested in large offices?

It looks like you are combining a few different concepts into one: copy validation, testing of restoration procedures, and fully restoring the entire enterprise. And It also looks like you are combining the difficultly of restoring data files and entire infrastructures. We need to pull this question apart.
Checksums are for validation of the integrity of the copy. It's not a "test". Validation is done at copy time to guarantee a faithful copy.
Infrastructure complexity does not make verification more difficult. It does create a complicated environment to test the restoration process. But this is easily accomplished using virtual environments, or dev/test infrastructure. I often use the virtual dev environment to restore core services and their dependencies. In one org, we would restore core VMs nightly from the previous backup/snapshot, run automated tests, and delete the VMs.
But for full enterprise restoration, that's a different matter entirely. I know of no org that tests an end-to-end restore of the entire enterprise infrastructure. At best, I have participated in tabletop exercises to map out dependencies and then we validated parts of the process. It is simply not feasible to test a whole-enterprise process, if for no other reason than the many risks that it can present.
So when people say "test your backups", what they mean is that you have tested that you can restore what you've backed up. It is best if you can test the end-to-end processes and to be able to restore the entire enterprise, but that's not expected because the costs, complexities, and risks get to be very high.

The reasons for testing are numerous and borne from a thousand horror stores.
Like:

The new tech who was taught the backup tape handling procedure from his predecessor but mixed up the process for packing up tapes for off-site storage and degaussing the returned tapes. The poor guy was degaussing the new backup tapes for months.
The tech who would flip the "copy protect" switch on the tapes before inserting them in the tape machine. The machine was old and didn't alert on this problem. The company had blank backup tapes going back years.
The tech who bought a cheap USB drive for backups, but the USB drive was fraudulent and kept overwriting old bytes to make room for new ones. It reported the saved files in the file system, but the files were not actually there.
The company who kept a very old tape backup system in operation, but the system was so degraded that the equipment was no longer able to perform reads from media, only writes. And the equipment used a proprietary format, so although the data was likely on the tapes, the company had no way of accessing it.

For all of these stories, a simple and regular test restoration would have highlighted a problem before the saved data was needed.


Linux /etc/shadow password change security

Basically it's using the suid bit. If you check the passwd command in your machine:

-rwsr-xr-x  1 root   root         43K Feb 15  2011 passwd

SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SUID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file owner rather that the user who runs it. In simple words users will get file owner’s permissions as well as owner UID and GID when executing a binary. So the binary is actually being run as root when you run it.


To monitor network devices there's essentially two possible protocols: Syslog and SNMP. Both work including for Wi-Fi. But for any detection to happen, you must configure your device to do so.

Many wireless routers log by default failed login attempts. If your actual router device is not sufficient to accomplish this because it does not support certain features, you can upgrade its firmware to DDWRT or OpenWRT.

Once you have a syslog or snmp working, you then can use quite many tools (SNMP Trap Watcher, Kiwi Log Viewer, SysAid Monitoring, SNMP Log Even sentry, etc) to analyze what is happening.


Your question about the version numbers in TLS 1.3 ClientHello -- note the record version is 1.0 (wire 0301) and message version is 1.2 (wire 0303), and as you note only the supported_versions extension says 1.3 (0304) -- is a crossdupe of https://serverfault.com/questions/907347/tls-1-3-client-server-hello-version-1-2 and now that RFC8446 is official is explained there.

It appears your actual concern might be that your connection attempt -- which is in fact 1.3 -- is not using ESNI. If so, the obvious answer is that the domain blog.cloudflare.com does not support ESNI, at least as defined in the draft; specifically it does not publish any TXT RR(s) at _esni.blog.cloudflare.com as required. The only domain I know cloudflare has announced to support ESNI is encryptedsni.com, and _esni.encrypted.com does have TXT RR containing ESNIKeys, although I didn't go to the trouble of installing Firefox nightly to test if it actually works. You might try that.


HTTPS self signed certficiate for personal website

The purpose of a public certificate infrastructure is to create a chain of trust between entities that don't trust each other directly. You pay the certificate authorities because other people trust them to issue certificates to trustworthy entities only.

Assuming you trust yourself (or whoever issued the certificate), self-signed certificates are no less secure than those signed by a public CA.

Similar and possibly relevant question: Is a self-signed SSL certificate much better than nothing?


That depends on the sophistication of the attack.

The likely scenario is that the vendor just added a malicious file to the driver archive. You could search for compatible drivers online to obtain a trusted version of the software and you'd be fine. (Does that piece of hardware actually need that custom driver or can you just use it without installing extra software?)

The bad case scenario is that the vendor went one step further and also modified the firmware of the device. That's something you can't easily verify and your only option would be dumping driver and hardware altogether. The BadUSB project was a good demonstration of how straightforward it is to hide malware in the firmware of peripherals, in that case reprogramming the controller chips of USB devices.

Most members of Sec.SE would probably advise you to assume the latter and not use the hardware at all. I'd say it depends on the situation and type of hardware on which you didn't give additional info.


Hashcat passwordcracking separator unmatched

I believe those hashes are  MD5(Unix) format, so -m500.
You can compare your hashes to the ones here: hashcat.net/wiki/doku.php?id=example_hashes.

By the way, $1$DcuX.dRK$bR4utyGQ4ET4sobpMMtfo0:bb


TCP Sequence Prediction and it's prominence in modern systems/networks

TCP sequence prediction was a hot topic around 2001, but most vendors have patched their OS quite quickly around that time. See this CERT advisory from September 2001, which includes statements from various vendors. Basically, if the TCP sequence prediction attack works against a system, then that system was not updated with security fixes from more than a decade, which almost certainly means that it has much bigger security issues.

To generate unpredictable sequence numbers, implementations are encouraged to follow the technique described in RFC 6528 (which supersedes the older RFC 1948). This is a custom PRNG with MD5. Cryptographically speaking, this PRNG kinda sucks: apart from using a hash function of questionable robustness, it also uses it "wrong" (that's a Merkle-Damgård construction; care should be employed when simply concatenating a key with some known input; HMAC should be used instead, as a building element); and the overall scheme is not very fast (a good stream cipher would be much better). However, speed is not a strong issue here (a low-end system will still be able to compute that algorithm millions of times per second; processing of incoming SYN requests will be the bottleneck, not the hashing) and we don't need really high cryptographic strength, since the attacker can "get lucky" with probability 2-32 anyway, so the PRNG needs not be better than that (typical goal for cryptographic algorithms is 2-80 or less).

Summary: TCP sequence prediction attack is a thing of the past; nice to know, but not applicable to systems which have been maintained for the last ten years or so.


Can someone hack my phone by sending me a file (e.g. PDF) via Whatsapp?

I recently read Hackers can use a WhatsApp flaw in the way it handles video to take control of your phone, so theoretically it is possible via PDF as well, depending on your OS and possible flaws in WhatsApp and your phone’s OS.


Why don't services like Have I Been Pwned send email if you haven't signed up?

First of all, Have I Been Pwned (HIBP) is not an authority, but a free service provided by Troy Hunt. There are actually many similar service providers, e.g. (some alternatives in an alphabetical order):

Avast Hack Check
BreachAlarm by Avalanche Technology Group
DeHashed
Firefox Monitor
F-Secure Identity Theft Checker
Hacked Leaks Checker (Android App)
Have I Been Sold by Bitfalls

Think what would happen if all of them starts sending you emails every time your address is involved in a breach! On the other hand, detecting a security breach typically takes long and only portion of the stolen data is ever made publicly available; e.g. in HIBP some of the data is added only days after the breach, but sometimes it takes years. There's a good chance some of the email addresses wouldn't even be in use anymore, even if there was a single authority sending that kind of notifications. Some of the addresses could even be faked.

BTW, not sending unsolicited emails to everyone is not the only way Mr. Hunt respects your privacy; you could even opt-out being publicly listed on the service.


Would this generated CSRF token be considered cryptographically strong?

I would say no. Here is an interesting article on a similar topic.

I would suggest:

Using a hash function (this does not add virtually any security on its own, but makes improvements mentioned below much more efficient), e.g. $csrfToken = base64_encode(hash("sha256", uniqid(mt_rand(100, 999) . microtime(), true), true));
Adding a long, random secret constant (this adds security while the secret constant remains secret - this value may be very easy read in shared-hosting server), e.g. $csrfToken = base64_encode(hash("sha256", "nS7W7@IEPJ~6&&vp#r>ziW-SGOC?s>!,.(s" . uniqid(mt_rand(100, 999) . microtime(), true), true));
Reading some bytes from /dev/urandom if this is available and adding them to value being hashed (this adds real security without use of PHP extensions mentioned in question post), e.g. $handle = fopen("/dev/urandom", "rb");
$urandom_data = fread($handle, 16);
if(strlen($urandom_data)!==16) exit("Unable to read /dev/urandom");
fclose($handle);
$csrfToken = base64_encode(hash("sha256", $urandom_data . "nS7W7@IEPJ~6&&vp#r>ziW-SGOC?s>!,.(s" . uniqid(mt_rand(100, 999) . microtime(), true), true));
Add client IP and port (this improves security a bit, especially if client IP address is not known to attacker), e.g. $handle = fopen("/dev/urandom", "rb");
$urandom_data = fread($handle, 16);
if(strlen($urandom_data)!==16) exit("Unable to read /dev/urandom");
fclose($handle);
$csrfToken = base64_encode(hash("sha256", $urandom_data . $_SERVER["REMOTE_ADDR"] . ":" . $_SERVER["REMOTE_PORT"] . "nS7W7@IEPJ~6&&vp#r>ziW-SGOC?s>!,.(s" . uniqid(mt_rand(100, 999) . microtime(), true), true));
This does not improve security, but makes the generation algorythm more understandable - remove uniqid() stuff and replace it with pure microtime(), e.g. $handle = fopen("/dev/urandom", "rb");
$urandom_data = fread($handle, 16);
if(strlen($urandom_data)!==16) exit("Unable to read /dev/urandom");
fclose($handle);
$csrfToken = base64_encode(hash("sha256", $urandom_data . $_SERVER["REMOTE_ADDR"] . ":" . $_SERVER["REMOTE_PORT"] . "nS7W7@IEPJ~6&&vp#r>ziW-SGOC?s>!,.(s" . microtime(), true));
(Added later) Add HTTP Cookie request header to input of hash function. This has dual effect on security - good part is that CSRF token depends also on session cookie (so attacker must know/guess victim's session cookie to calculate CSRF token - in most cases session cookie is more critical); bad part is that attacker may try to "guess" session cookies based on any CSRF tokens saved in browser history. To make this guess computationally harder (at the expense of server resources) Cookie header can be hashed alone before adding it, e.g. $handle = fopen("/dev/urandom", "rb");
$urandom_data = fread($handle, 16);
if(strlen($urandom_data)!==16) exit("Unable to read /dev/urandom");
fclose($handle);
$csrfToken = base64_encode(hash("sha256", $urandom_data . $_SERVER["REMOTE_ADDR"] . ":" . $_SERVER["REMOTE_PORT"] . "nS7W7@IEPJ~6&&vp#r>ziW-SGOC?s>!,.(s" . microtime() . hash("sha256", $_SERVER["HTTP_COOKIE"], true), true));

P.S. Notice that variable-length digit strings are concatenated using non-digit separators (to avoid some non-equivalent string sets resulting in equivalent concatenated values).

P.S.2 Looks like there is a bracket (")") missing in question post code.

P.S.3 More on meaning of cryptographic hash function here. Hash function does the following:

Adds NO entropy - has functions are deterministic (hash function will always produce the same output from each particular input). It is important to understand that no entropy is added (even if length of string is increased). SHA-256 from string "A" will be 32 bytes long, but it will still be a well known value (you can just Google this hash in hexadecimal to find out how popular it actually is).
Mixes and obfuscates (this time obfuscate does not mean something avoidable and insecure) the input - the only way attacker can determine the input is by guessing it. Basically hash function introduces an all-or-nothing principle - either attacker knows entire input (and can verify it by computing the hash) or attacker does not know which parts of the input he has predicted are correct. As a result hash function allows to increase security by adding a long, random secret constant (step 2 mentioned above), without use of the hash function attacker would see the constant in all observed CSRF tokens (thus he would know what the constant is and that it must be added).
(Very closely related to 2.) Makes attacker to spend some computational resources with each "guess" of the input of hash function. In article mentioned above the attacker uses GPU (video card), because he must do large number of "guesses" and that would take very long time on CPU. The more complex (less predictable) input of the hash function is, the more computational resources attacker must use to guess the input. If the attacker has enough computational resources for "guessing" the input of the hash function used to generate CSRF token (as said before, amount of computational resources needed depends on complexity/predictability of the input), he can sample the input and start to analyze how it is composed, identify constant parts etc.

For further reading on application of cryptographic hash functions the following Wikipedia articles are relevant: Cryptographic hash function, Hash-based message authentication code.

P.S.4 Partial off-topic: As mentioned earlier, it can be easy for an attacker to extract the constant and generation code by attacking shared hosting environment.


How can I inject real php code into this website?

This is... strange. My guess is that you are right in that this is some sort of protection mechanism, but it doesn't look like a very stable one. A better approach would be to block files with .php or similar extensions, and on top of that turn off PHP execution in that folder.

So can this be exploited, and if so, how? I am not sure, but here are a few things to try:

Different PHP tags (<?, <?=, <%, <%=, <script language="php">).
Insert whitespace and try different cases, e.g. <?PHp or <? pHp. (Not sure if the PHP engine will recognise this, though.)
Leave out the closing tag, try nesting tags inside tags, and so on.
Maybe it only does the replacement for PHP files? Then you could use .php5 or .phtml or similar instead.

To figure out a bypass (if there is one), you need to guess how the system works and test your theories. E.g. if you suspect it simply replace all < with <!--, send in a lone < and see what happends! Don't be afraid to experiment. Trial and error is your friend.


Disadvantages of metasploit Framework for windows

For one, it might not work at all. I tried recently(in April 2012) on two Windows machines (7 and 2008 R2), and some aspect of the PostgreSQL setup invariably fails.

I spoke to a Rapid7 account manager about it, and he confirmed that the Windows version is flaky.

He also recommended against using it in a production environment.


How to kill a process with multiple threads?

If you can either identify how the malware is started on boot or where it is stored one possible option would be to shutdown the machine, boot from another medium (such as a Linux or Windows PE live USB) and make changes from there to stop it launching on next boot. This will involve either removing files containing the malwares executable code or modifying system configuration to stop it from launching again on boot.

If you are strugling to identify the executables follow the steps suggested by baldPrussian -

  Get the names of the threads, which can tell you the executable that runs. Find where the exes are and the reg keys (possibly the run key) that call them

I would suggest checking the system multiple times over the next few days to ensure nothing was left on the system to allow reinfection. You also want to do everything possible to determine the infection vector - again so you can take steps against becoming reinfected.

If worst comes to worst swallow your losses and nuke it from orbit.


How easy is it really to do IP spoofing?

Actually, you can't. Whenever you need IP traffic to be bidirectional, IP spoofing is no use. The contacted server would not reply to you but to someone else, the address you spoofed.

IP spoofing is then normally "useful" only to disrupt communications - you send harmful packets, and you don't want them being traceable to yourself.

In specific situations you can use a double spoofing to gather a measure of bidirectionality. For example let us suppose that we know of a system somewhere that has poor sequence generators - whenever you send a packet to it, it will reply with a packet containing a monotonically incrementing number. If nobody was connecting to the system except you, you would expect getting 1, 2, 3, 4... .

Now let us further suppose that you're interested in whether another system is replying to specific packets (e.g. you're running a port scan), and you wish to receive some information but don't want the target system to have your real address. You can send to that system a spoofed packet pretending to be from the poorly-sequencing machine.

Now there are three possibilities: the target system does not reply, it replies, or it actively counterattacks and (e.g.) scans the pretended source to determine the why's and wherefore's of that first packet.

What you do is, you scan - without spoofing - the poorly-sequencing machine (PSM). If nobody except you has connected to it, which means that the target machine hasn't replied to the PSM, you'll get 1-2-3-4-5. If it replied once, you will get 1-3-5-7 (the packets 2, 4 and 6 having been sent by the PSM to the TM in response to the TM-PSM replies to the spoofed packets from you to the TM. If the TM made more connections, you'll get something like 2-11-17-31 or such.

The PSM knows your real address, of course, but the TM does not. This way you can spoof a connection and still gather some information. If the PSM's security level is low enough, this, combined with the fact that your "scan" of the PSM is harmless, is (hopefully) enough to prevent consequences to you.

Another possibility is to spoof a nearby machine. For example you are in network 192.168.168.0/24, have IP 192.168.168.192, and you have promiscuous access to some other machine address space, say 192.168.168.168. You just have to "convince" the router serving both you and the .168 machine that you are indeed the .168 machine, and take the latter offline or disrupt its communications (or wait until it is offline for reasons of its own, e.g. a colleague logging off for lunch). Then the replies to the spoofed .168 packets will sort of whizz by past you, but as long as you can sniff them while they pass, and the real .168 isn't able to send a "That wasn't me!" reply, from the outside the communication will appear to be valid and point back to the .168 machine.

This is sort of like pretending to be your front door neighbour, while that apartment is really untenanted. You order something through mail, the packet gets delivered to the other's front door, you tell the deliveryman "Oh yes, mr. Smith will come back in half an hour, I'll just sign for him" and get the package.


Can attackers substitute/place my queries to/from provider?

This happens all the time in situations that do not need an attacker. A "proxy" is a server that funnels all connections through it and then passes it on to the real destination. A proxy can modify all the data passed through it in either direction to do things like remove images, or display a safe page if the user has navigated to an unapproved site. This kind of thing can happen in companies, schools, or government buildings to protect the users.

But, yes, attackers can do the same thing in an attack called "Man in the Middle". The most common example is at an open public wifi (like a coffee shop), where an attacker funnels all your traffic through his computer to read (or modify) the traffic.


Diffie-Hellman and MIM attack, and server identity

Diffie-Hellman and MIM attack:
  When variants of Diffie-Hellman algorithms like DHE, ECDHE etc. are used in SSL handshake for key exchange then can it become prone to man in middle (MIM) attack.

  Suppose, SSL handshake has started and now it is time of key exchange, so client computes its public key part of DH and sends it, now bad guy sitting in the middle intercepts it and computes its public key part of DH and sends it. And then both computes the shared secret from each other's public key and shared secret is established. Now even though the traffic is encrypted using the shared secret but since the bad guy did all this, so he will be able to decrypt it. No?

  In case of RSA, since anything encrypted using public key can only be decrypted using private key so it is safe. I am sure about this, but with DH I am getting above doubt.

It seems you are describing something like the scenario below (source):

Notice that the man in the middle replaces the certificate and public key for the legitimate domain with their own cert and public key before DH parameters are exchanged. The MITM then uses their public key to sign the DH parameters. Now what should happen is that as soon as the client receives the cert it should check that the cert is issued for the domain it thinks it is connecting to (Server S). When it is presented with a cert for a different domain from the MITM (Server A) it should reject that cert and not proceed with key exchange. In a more concrete example, consider a client wants to connect to https://www.google.com and instead of getting a cert for the domain google.com it gets a cert for the domain evil.com (signed by a trusted CA). Obviously the client should not interpret this cert as being valid.

  Server identity:
  Suppose cipher is TLS_ECDHE_RSA..... Now, as I understand ECDHE is for key exchange and RSA is to prove server identity or authentication. But how RSA is used to prove the server identity or authentication because it is done with digital signature, right? Client will see the server's DC is signed by a trusted CA and he will identify and trust the server. Then how "_RSA" or "ECDCA" part of cipher suite comes into picture to prove server's identity or for authentication?

  I have read a lot of algorithm explanation for key exchange thing but never about server's identity or for authentication from "_RSA" or "ECDCA" part of cipher suite.

Yes, the cert that the MITM presents may well be valid and signed by a trusted CA, but the MITM cannot get a certificate for Server S.

Note that there have been cases where the domain in the cert is not checked against the domain being connected to (such was the case in the Chase mobile app for a while!), you can read about such cases in this paper, but this is an implementation issue, properly implemented TLS does not allow this scenario.


Is it unsecure to let my personal computer user name be known publicly?

In theory, any information about a computer is helpful in attacks. What you did was disclosed recon information or partial user enumeration.

But practically? If the username is not your real name, or doesn't contain any personally identifiable information such as birth date city or anything of the sort and is purely a pseudonym? No don't worry about it.

Targeted attacks on personal computers require more information than just a user name, a lot more, and usually the goal would be some sort of reverse shell that will either be within the permissions of a limited user (your account name) or root, depending on the exploit. In the case the shell results in a user, the attacker already knows your account name. In the case of root, he doesn't care.

And blanket attacks are only effective if they don't rely on enumerables such as usernames so again they don't care.

I think you're fine.

EDIT:

Personally I would blur out any information that distinguishes my computer from any other, but I'm the paranoid sort. I would advise you to be conscious of this sort of thing in the future, but I wouldn't lose any sleep over this one.


Is randomizing cookie names a good idea?

I don't think you gain a lot since they'd still be associated with the site, or some sub-domain of it.

As for the downsides, you'd have to have some lookup to figure out what the name for a particular cookie is so you can know where the data you stored previously can be found.

I think you're better off not worrying about it, and instead make sure you only store some unique identifier so you can tell who it is, provide adequate security to keep others out of their account, and store all other user-related data internally in your own back-end database.


Is it safe to set up your firewall to allow localhost to accept incoming connections?

The localhost in general is used to verify that the TCP/IP stack is correctly working on the host for example. Some programs use localhost for communicate process on the same host. Is very common to do what your RStudio is telling. Bear in mind that you can not ping externally to localhost from other host, localhost is only accessible on your host, so I don't see any problem of having that iptables rules, wait other answers :)
Hope it helps


OpenSSL 1.1.1b warning "deprecated key derivation used"

To ignore it, just ignore it the way you ignore anything, by not looking at it or paying attention to it. I will consider that you want to suppress it, so it isn't there to be ignored.

On Unix and Windows (which is most of the places OpenSSL is run, though not all) use 2>/dev/null or 2>NUL: respectively to discard all error messages.
As it says, use -pbkdf2, or -iter which implies it, to do a better password-based derivation.
Use an explicit key and IV (for CBC) with -K -iv to avoid any password-based derivation.
Use a version of OpenSSL lower than 1.1.1; although 1.1.0 is off upstream support and 1.0.2 will be very soon, they are still supported to some extent (at least provided) by many packagers and distros.


Should I use my personal laptop to login into company portal?

Access to company email is more than enough to cause anyone pause before accessing with a personal device. You might not have access to code repos, but you have access to a lot with email.

The problem here is having access to company emails on your personal device. Malware isn't a huge threat, but theft or compromise of your device is. If someone can gain access to your work email through your device (of dubious security), that's a problem.

That's just an initial response from someone who has written policy around such things given the few details you provide. I'd want your personal gear far away from corporate email.


Since javascript uses UTF-16 strings, I suspect it is expecting a UTF-16 encoded string.  Just to clarify, your first parameter should be a hash algorithm ('sha1', 'md5', etc.) not the data to be encrypted.


Different virus types of testing on a Windows VM

If you can't find any compex viruses to match your requirements, why don't you create some? Use leading malware creation programs and techniques by yourself! For example, you can use metasploit framework and many other tools to create a bunch of different well-know types of viruses, encode them, obfuscate them, pack them etc. Also, try to inject malicious code in legit applications. Creating a small fleet of custom viruses, using different techniques to trick anti-virus programs, will give you both better knowledge of malwares and far more superior results on your research.


Problem regarding beacon frames and bssids

try this:

ifconfig wlan0 down
aireplay-ng --deauth 100000 -a 06:CB:51:F8:6B:5F -c 64:89:F1:07:CC:4B -D wlan0

Disable wlan before attacking and disables AP detection.
Some modes will not proceed if the AP beacon is not heard. This disables this functionality.[1]


What are some ways to spot email spoof attacks?

You will need to analyse message headers to determine what is going on.

Google's Message Header Analyser is here.

Using the tool, check the from servers to find out if the emails pass through your contacts' servers or only your own.

Also check whether SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) pass - if they do pass, it is more likely to be a compromise on your contacts' servers or accounts.


Dealing with shared credentials when an employee leaves

First, re-engineer your account management process, where possible, so that users have personal admin accounts and the built-in admin account is disabled, or that built-in account password is stored in a secure location such that your admins cannot get unauthorised access to it (e.g. password vault).

Second, if you cannot use account separation on the device/service level, then consider using one of the many privileged access tools or Cloud Service Brokers (CSB) (e.g. CyberArc, Thycotic, etc.) so that only the system knows the password and account separation is achieved on a management layer. Blocking access to a user is a 1-click operation in the tool. Changing passwords is equally easy and the authorised users experience no change or inconvenience.

Third, even if you do the above, you have a manual documentation and audit process to engage:

document all services that need to be managed
document all accounts and users on each service
review all accounts/users on a periodic basis (annually? quarterly? monthly?) to confirm fitness
audit the completeness of all services and accounts

Obviously, a privileged access tool or a Cloud Service Broker is the way to go for consistency and uptime.


Will Intel's MPX extension make C/C++ completely safe to use?

Firstly, C++ has enough degrees of freedom that a computer cannot make it completely safe. C++ literally gives you full access to anything the CPU can do.

Functions like fscanf are just routines that do looping and checking internally to give you higher-level functionality. However, fscanf has no knowledge of how far a buffer goes (I.e. how big it is). The only part of the code that does have that information is the malloc library, but that's also just a higher-level algorithm to make things easier that the hardware doesn't know about.

Theoretically, the compiler can store this information and pass it to the MPX extensions, but in many applications that will be nearly impossible to do because most things are stored as void* and passed around manually so a static analyzer cannot have the requisite information to set those registers. The only way to do this would be to store additional information at runtime, thereby changing the size of void* which would violate the rules of C++, so it would have to be a special type that very few developers will actually implement because it will cost too much.

A buffer overflow happens when the developer is lazy with their power, not when the hardware messes up.

This is just one of the possible bugs in software that make it insecure. There have been SEVERAL bugs which are integer overflows, invalid logic, etc.

So no, it will not make C++ completely safe to use - nothing will.


Why not to use the same subordinate issuer CA for generating certificates that will be used for different things?

Using different intermediate CAs will allow you to differentiate end-entity certificates by their issuer. This makes it possible to create trust rules that will limit certificate usage based on their issuer.

Issuing all your certificates from the same iCA will make it easy to mistakenly allow one certificate to be used for something unintended.

That will, for instance, allow you to generate wifi authentication certificate from iCA1 and TLS client connection certificate (web services) from iCA2 and then to configure your wifi access point to trust any certificate issued by iCA1. This will prevent certificate you issue for your web services to be re-used for accessing your wifi network (and the reverse) without having to mess up with custom OIDs in certificates (which might not even be supported by the software making use of these certificates).

You could do the exact same thing with separate CAs except that this require more management effort.


Go to Control Panel\User Accounts\Credential Managerand you'll see a list of locally saved password for windows. From there you can make a backup as well as add, delete and change entries.


TL;DR: I don't really find any points that are positive to enroll your own Security. You can try to implement the Basic concepts of SSL in some dummy application to learn how it works but beside that you shouldn't even consider that to use it in Productive. For your own sake and for that of every user that should use your application.

Beside the Point of "don't roll your own" (which is always an argument that kills the need of a own implementation because a "normal" developer can't develop it correctly) according to Martin's points:

compile time -> you won't compile the entire SSL Library, you will use it. So use an external one is faster than your own
repo size -> you use the Library, your own implementation would be much bigger
we only code the stuff we need -> you do exactly that ;)
experience -> ok, you will learn the basics of SSL. But if you then program something which is broken in the beginning and you think that this code is correct, you will learn something wrong and thinking it is correct. That is much worse then learn how to use a well known library
license stuff -> yes you maybe must put some text in your application that says you use that library. But then go to different big applications (example may be Android OS) and go to their License Part. You will (if it use SSL) always see the openSSL library license text there
it would be cool -> what is cool on build something that is not good ;)

Additional:
 Always try to use Libraries that are well know. You don't need to fix bugs inside of them, they are reviewed by more eyes you could afford and bugs are much faster found than in your code (your 10 000 user vs. their 1 million users as example). Further more are well know Security Libraries very often checked by Experts that know what they doing ;)

The best code is that one you don't write.


How to search for malicious software added after a recent date

Modification dates are not trustworthy at all. ClamAV doesn't even scan for Linux malware, it just allows a Linux machine to find Windows malware in files that it hosts.

Without physical control of the machine it is certainly possible that someone could have installed malicious hardware such as a keylogger or modified existing hardware, but that would be a relatively expensive thing to do for no reason. Do you have a reason not to trust the Apple repair employees? Are you concerned about a specific threat?

Installing malware would be the most likely "drive by" attack since it is basically free. The most effective way for you to ensure the integrity of your system in this case would be to perform a fresh install of the operating system onto a clean wiped disk. Backup your important files, but not any executable files. Change all of your passwords from the freshly installed operating system.

I cringe at the thought of sending my machine in to a repair place, and probably would do the system wipe immediately at a minimum. I would have wiped the machine before sending it as well.


Is this doable? Of course yes.

Is this a reasonable thing to do? It depends on what you goal is. If you only want that your child or girl friend can play winmine with little to no risk for you sensitive openSUSE partition, that is fine. That means a reasonable protection against mistyping on a keyboard without true malice. And if your girl friend is not a computer specialist, it can even be enough to hide the mere existence of the second system.

If you are looking towards plausible deniability, it is no longer reasonable at all. Anybody with standard knowledge on computers will see immediately that:

the windows partition does not use the full disk size
another partition exists and looks bootable - I'm not an expert on openSUSE encrypted partition, but as the goal is only to protect data, I would suspect that it is easy to guess that the other partition contains a Linux system.

VeraCrypt documentation contains a full chapter about it explaining the limits of their solution which is still accordingly the linked Wikipedia pages among the best existing and maintained ones.


Is it good practice to ban an IP address if too many login attempts are made from it?

The answer to this question very much depends on the security posture of your site, which decides whether the risk of unauthorised access is greater or lower than the risk of Denial of Service for some users.

For high risk sites, I might go with the blocking option, especially where most of the user base is likely to be home users and therefore is likely to have distinct IP addresses.

One compromise might be where you detect password guessing attacks, add some anti-automation (e.g. CAPTCHA) to logins from that IP address for a while.  That has the effect of making the attack harder to pull off while not completely blocking legitimate users from the site.

If you still get lots of invalid logins with the CAPTCHA completed then it would sound like you're seeing a more targeted attack (as they'd likely need to pay for a CAPTCHA solving service if your CAPTCHA is any good), and at that point I'd be more inclined to block the IP address for a while and redirect users to a message explaining the block (something like "malicious activity has been detected from your IP address, please contact support on [your_support_email_here]).


IIS IP Address Restriction - can I rely on it online?

Really does depend on your threat model, how valuable is the information and functionality offered by the web service? What type of attackers and specific attacks are you worried about?

IP address restriction is the most basic form of protection and really does not give you any security. It is trivial to bypass via a proxy for example. Also if you whitelist a corporate public address, you have no idea what machines behind that NAT are connecting. So if it is a basically a public service or you are using IP address restriction as a defense in depth mechanism to authentication then that is fine otherwise you are getting no security benefit and may as well not do it (for the trade-off in additional management and troubleshooting). Getting users to install anything with the troubleshooting and support this involves is generally a very bad idea.

If it is a valuable web service the standard way to authenticate is:

Mutual authentication via certificates. http://msdn.microsoft.com/en-us/library/aa292114%28v=vs.71%29.aspx . This provides you strong authentication and no passwords to manage. A certificate cannot be brute-forced nor guessed and you provide assurance to the third parties that they are connecting to the genuine service. You can cut the certificate cost by using something like startssl.com but you do have to issue, support install, renew, revoke certificates
API key - the other most popular method is to provide an API key for each user of the web service. This is effectively a password and carries all the risks and benefits of a password. You need sufficient length, complexity, lockout/back-off to mitigate brute-force and guessing risks

I would be very careful about putting a web service designed for an internal corporate environment meant to be used over a VPN on the Internet. I would recommend getting it security tested from an application and infrastructure perspective before you do this. There is a high likelihood of cross site scripting, SQL injection and other common web application vulnerabilities especially if you are using REST web services.


Why is it bad to use your browser's password manager?

The biggest problem with saving your passwords in your browser is that it's not hard for someone who gains access to your computer to also access all your passwords.

In Chrome, for example, you (or anyone who hacks into your computer) can just go to the browser's settings and click on the show button in the preferences tab to reveal any saved password.

There are some tools that will reveal the passwords stored in the browsers.

http://www.nirsoft.net/utils/web_browser_password.html

WebBrowserPassView can't retrieve passwords that are encrypted with a master password, though. That makes Firefox the most secure of these three browsers when it comes to password management, because you can encrypt and password-protect your logins in Firefox with one master password.

If you don't set the master password in Firefox (which is not enabled by default), though, you are re vulnerable to the same security issues if your computer gets into the wrong hands.