I'm conducting a study involving passwords, and need a method that assigns a numerical value to the complexity of a password

In short there is no reliable way to do this. Your program would have to implement a set of rules. Humans then work around these. I.e. requiring a number makes 99% of average users passwords no more secure - they just add a 1 at the end of the existing password. The same with symbols.

"p@55w0rd!" would score highly on a lot of prior attempts at rating passwords. As would "This is my password!". Meanwhile "lbvgjnwhha" (randomly generated)  would score poorly because its a fairly short string of all lowercase letters.

Instead I would consider a different approach. This page, for example can check a password against hundreds of millions of known to be leaked passwords. This should defeat most non-targeted (i.e. personal attributes like surname, date of birth etc.) dictionary attacks. You could demonstrate this (or download the full password hash lists and write a tool to calculate the hash for an entered password and check it against the list) while explaining password best practices & the benefits of two factor authentication.


Offline RSA strong prime test similar to Phuctor?

In general, there is no clear distinction between "hard to factor" and "not hard to factor" RSA keys. This is a continuum. For instance, the ECM algorithm (that uses elliptic curves in a smart way to factor integers) tend to have a computational cost that depends on the size of the smallest factor of the target integer. If you try harder then you can find larger factors. The consequence is that even if you spend one full day of computations to "try" with ECM your modulus for small factors, and find none, then you don't know if an attacker with more patience might not find a factor by devoting two days of computation.

There is no known method that can test a given integer and return the size of its factors, without actually recomputing the factors, which is (hopefully !) computationally infeasible for a proper RSA key.

Testing RSA keys after generation is a fool's quest. This is a nice thing to do to detect some poor implementations, not poor keys. Moreover, it detects only certain classes of poor keys (specifically, those with small factors). It does not detect poorly seeded RNG used in an otherwise correct RSA private key generation. This highlights an important point: while having very small factors is a sure sign of flawed key generation, having only large factors does not guarantee secure generation.

For proper security, ensure that keys are properly generated by auditing the key generation process, not the result.


How to block local ip with Windows Firewall?

If you want to block access from 192.168.178.10, it should be added to remote IP address instead of the local IP address.


change read/write user permissions in windows server 2012 from java code

Launch an External Application

You can use ProcessBuilder to start a Process where PSExec is used to execute processes as a different user.

psexec.exe -u username -p password foo.exe

https://technet.microsoft.com/en-us/sysinternals/pxexec.aspx

Change a Windows Server 2012 R2 User's Permission

For executable file, you can use Icacls.

https://technet.microsoft.com/en-us/library/cc753525(v=ws.11).aspx

For PowerShell script, you can use Get-NTFSAccess, Add-NTFSAccess and Remove-NTFSAccess.

https://blogs.technet.microsoft.com/heyscriptingguy/2014/11/22/weekend-scripter-use-powershell-to-get-add-and-remove-ntfs-permissions/


I would suggest you look at whether or not you can actually do anything with those files on the system you're looking at securing as a regular user.  Most likely, you will find out that most of the really important ones (storage devices for example) already cannot be accessed by regular users, because that's the standard configuration on a vast majority of UNIX systems, even as far back as 4.3BSD and SVR4.  If you're being truly realistic, disallowing non-root access to these device files is probably sufficient for security (if the attacker has root access, device files don't matter because they can probably get code running in kernel space easily, which doesn't need device files to poke at hardware).  If the system in question is configured to use SELinux or another LSM, you can also leverage that (if the default configuration doesn't already) to further limit access.

Even if you hide or block paths under /dev though, that doesn't really prevent people from creating new device nodes elsewhere with the appropriate major and minor device numbers and arbitrary permissions.  You can't easily stop people from creating such files, but you can make them essentially useless by mounting everything except /dev with the nodev mount option, which disables special handling of device nodes on the mounted filesystem.  Properly doing this requires that your root filesystem be separate from /dev (which should be either some automatic virtual filesystem provided by the kernel (such as devtmpfs) or a tmpfs instance populated by a device manager).

Beyond that, a lot of the really nasty ones (/dev/mem, /dev/port, /dev/kmem, and /dev/msr, as well as /dev/hpet) can be completely disabled at compile time.  This doesn't just keep them from appearing in /dev, it means that you literally can't ever have working instances of these device nodes on the system.  Most Linux distributions explicitly disable /dev/kmem these days because nothing uses it, and a lot of them also disable /dev/mem and /dev/port because they are largely only used by legacy software.  /dev/msr on the other hand is usually built as a loadable module (and thus can be explicitly blacklisted without rebuilding the kernel) because there are actual practical uses for it that don't involve attacking the system (for example, debugging CPU power-management issues).

Also, as a sight aside, don't block /dev/null or /dev/urandom, you'll probably break your system if you do, and neither one is a really an attack vector.


Optimal way to capture HTTP(S) traffic on proxy-unaware iOS applications

This has been a rather interesting turn of events, apparently, the issue with VPN/Burp Suite method had to do with my configuration of the Burp Suite's invisible proxying (in which I neglected after troubleshooting a few times) as answered in the ServerFault question I posted previously. To contribute back to the community, here's a tutorial on how to MITM a proxy-unaware iOS >10 app!

Guide on MITM'ing a proxy-unaware iOS app for iOS 10 and above

Setting up the VM

Set up a Linux VM of your choice (I used Linux Mint, but Ubuntu and Debian based distros work just as well with the rest of the tutorial), and download Burp Suite, preferably the JAR version as it is more portable.

Install OpenVPN as per DigitalOcean's guide. Double check that your iOS device can connect to the VPN and that it can access the Internet.

iptables configuration

You should have already configured your iptables as per the guide above for masquerading client connections. You now have to configure iptables to forward all HTTP and HTTPS requests from OpenVPN's tun0 interface to port 8080 (or whichever port your copy of Burp Suite is using)

# iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 80 -j REDIRECT --to-port 8080
# iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 443 -j REDIRECT --to-port 8080

The fun bit

Launch Burp Suite, making sure to:

Disable Intercept: you don't want to stop and inspect/edit every single connection unless you need that feature
Proxy > Options > Proxy Listeners > Edit and enable listening on all interfaces
Proxy > Options > Proxy Listeners > Edit > Request Handling and enable invisible proxying or none of the above will work!

Have fun ;)


TLS handshake proof of private key posession

There doesn't have to be any explicit proof of possessing a private key.

When you present a client with your certificate, the client will respond by encrypting data with the public key present in the certificate. If you don't have the private key, you will not be able to decrypt what the client sent hence the connection will not move forward. @adam86 pointed out that my answer was not clear. What I meant was that up untill you have a Diffie Hellman key exchange, the messages are encrypted using the public key. Once a symmetric key(session key) is established, it is used for the rest of the session.

What a motivated attacker can instead do is create their own certificate and act as if they are the actual server (man in the middle). This is still possible in SSL/TLS.


I don't see anyway to reconcile these two RFCs

There are two ways to reconcile them:

Choose Security (RFC 7465) over Backwards Compatibility (RFC 3501)
Choose Backwards Compatibility (RFC 3501) over Security (RFC 7465)

  I have seen that Google has turned off RC4 on its email servers and is
  requiring TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, but that's not
  necessarily interoperable with the rest of the world.

Google chose option #1.  They probably took a census of all their IMAP traffic, reviewed the Client Cipher Suites being suggested, saw that either nobody or a negligibly small number of clients would be impacted, and then shut off RC4.

  Is there an update to RFC 3501 coming that changes the mandated TLS
  cipher suite?

Doubtful.  RFCs require common sense.  It is to be expected that narrow technical recommendations like mandated ciphers in an otherwise large specification will be overridden by later, more specific RFCs.  Nobody's going to go revise the IMAP RFCs just to make sure they reflect current TLS practice; everybody is expected to vote with their feet with current TLS practice.

This is all in line with the special status of RFCs - they're rules, which everybody has to follow, except when they aren't or they don't.  The only force an RFC has is the critical mass or people paying attention to it.


It sounds like you want to have a custom shell environment for this one user. Replace bash with a custom variant that only allows certain commands and logs the other commands.

Kippo/Cowrie would be a good model for you to look at for creating something like this and all the challenges and limitations, as well. Kippo/Cowrie is for faking ssh shells.


I think I found the reasons why PKCS is used with RSA in SSL!

First of all, it's important to know that (Textbook-)RSA encryption is deterministic, that means a message m encrypts under the usage of the same public key e every time to the same cipher text c because c = m^e mod N.

Especially short messages can easily be calculated by an attacker because if m^e is smaller than modulus N, one just needs to calculate the eth root of c (because the modulus operation was never applied to m^e). m itself must be smaller than N, so: m < N and m^e > N

  So why is the PKCS encoding needed? Just to bring in more randomness before encrypting the pms?

As stated above: (Textbook-)RSA is a deterministic encryption without randomization, so the attacker could just try a lot of different pms values until one of them results in the same cipher text as send by the victim.

So even if the pms is already a random value, the PKCS encoding adds more randomness which makes it harder for attackers to guess the pms by testing multiple different values.

  Why must the length of the encoded pms equal the length of the RSA modulus in bytes?

The longer the plain text the more values one must test for a successful brute force attack. But as stated above the length of a message m must be smaller than the modulus N but m^e must be bigger than N.

So the PKCS encoding increases the length of the pms to its maximum (same byte length as the modulus N) but it's still smaller than N because the PKCS encoding starts with 0x00. But because of its maximum length it is made sure that m^e is bigger than N.

  Also, the PKCS encoding seems to be the reason why the Bleichenbacher attack was possible. So what advantage can be found in using PKCS?

The Bleichenbacher attack was possible because the server's error messages helped the attackers to narrow down the possible values for the pms until only one value was left.

Deactivating those error messages solved the problem.

In PKCS#1-2.0 the Bleichenbacher attack was fixed.


Permissions to set for Secure internet browsing in Windows 10 (Pro)

What you're asking is really a discussion chocked full of opinions, suggestions, positions, guesses, and what about gotchas. Despite the voice in my head chanting, "Don't Do It ... Don't Do it ..." I'm going to make some observations.
Yes I know, this doesn't answer the question.
As far as Internet Browsing is concerned, there is no effective difference between Windows Home and Pro. Perhaps you're thinking bitlocker encryption is a protection factor, it's not in this circumstance.
The Microsoft provided Malware/Virus protection is highly rated. It's easiest to stick with that.
Creating a non-admin User account and using that is highly recommended.
Most malware infections these days do not come from direct Browser interactions or exploits. Modern Browsers do an excellent job of living within operational security constraints. The classic click a link and get infected would be a rare 0-Day you are unlikely to ever encounter. Personally, I recommend using a non-Microsoft Browser because it is not tied so tightly with the operating system, but that is arguably a personal bias.
The fact that you've encountered malware compromises in the past suggests your usage habits need evaluating.
Malware infection onto you machine is almost always because you chose to execute a dubious program.
So how does that happen?

A pop-up - Malware detected from your machine. Run this cleaner.
No! Just No!

Your Browser cannot play this video. Allow this video player to install in order to play this video. No!

Your machine has been detected doing bad things. Allow repair access? No!

Girls waiting for you. Click and allow Hotgirls.Bikini.Huge.Waiting.jpg.exe . No!

"Dude, look at the awesome program on this thumb drive my bud gave
me." No!

If you feel you need to run dubious programs, do it on a disposable machine.


The short answer is No.

This is a classic example of Security through obscurity which while it may work sometimes is considered a bad idea because it never works out in the long run.

As in my answer to the other question it comes down to threat modeling. Consider the following two scenarios.

1) Attackers have downloaded a database of usernames and passwords with all the passwords stored as SHA1 hashes. They use rainbow tables or a dictionary of common passwords and try to break the weak passwords.

Is your system more secure? Yes, csbthaapolteotrerrryseect is unlikely to be in a password dictionary.

2) Attackers have downloaded a database of usernames and passwords with all the passwords stored as SHA1 hashes. They are targeting you and know your function, or maybe your function becomes wildly popular (like the xkcd one has) so the attackers run your function over their dictionary.

Is your system still more secure? No people will be looking for csbthaapolteotrerrryseect and similar passwords.

Kerckhoffs's principle is often used in cryptography and states that

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

This is a great asumption and it is used in the xkcd comic. Even if you know everything about how I generate passwords (including the list of words I use) there are still 2^44 possible passwords. Plus the huge advantage of the xkcd style is that it's easy to remember and type.


What does the field vuln-security-protection stand-for in the NVD cve lists 2.0?

This FAQ about assigning vulnerability types implies that <vuln:security-protection> indicates that a vulnerability can be leveraged to gain access to a system.

Access is the holy grail when trying to compromise a system since if you have access you can then compromise the system in any other way you want (availability, integrity, confidentiality).

The presence of the <vuln:security-protection> element indicates that the vulnerability impacts on access rights while the value (ALLOWS_ADMIN_ACCESS etc.) indicates the level of impact.


The cloud centre provider's location is not going to be in your scope. You will "control" them through A.15 Supplier Relationships of the standard. You will not have direct control over their physical location. It will be treated as you say via SLA. The only region in the scope may well be the office accessing the data located in the cloud as well as what the standard calls "teleworkers" i.e. those who are remote.
Hope that helps!


Does unpatched software comply with PCI DSS 3.1?

For critical bugs, the PCI DSS 3.1 Quick Reference Guide covers this in no uncertain terms:

  6.2: Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

This is mirrored in the official documentation for PCI DSS 3.2 (I couldn't find a v3.1 PDF) which says exactly the same thing:

  6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

  Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

To save you a long read, the TL;DR of requirement 6.1 is that criticality should be measured based on industry provided CVSS scores amplified by business factors.

In more general terms, the question of whether or not they are in violation of PCI DSS when they are running outdated and vulnerable software depends on the decision of their QSA. If the bug is minor, such as a static content injection issue or minor information disclosure, then the QSA may consider it appropriate that the organisation identified the issue and placed it on their risk register for future resolution. If the bug is more severe but not considered critical (e.g. reflective XSS requiring user interaction), the QSA may still consider this a violation of PCI DSS at their discretion.

With regards to EOL software, PCI DSS does not mention it specifically, but simply states that

  All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

This indicates that using EOL software becomes the responsibility of the organisation handling cardholder data. Should a vulnerability be found in the application, it is up to the organisation to mitigate this. This may require them to manually patch the application (difficult, expensive), provide secondary controls (e.g. placing the application in an isolated container environment such as XenApp), or replace the software entirely.

For more information, I suggest you give the PCI DSS documentation a read for yourself. It's quite a long document, but you can skip to sections applicable to your concerns, and the language is quite clear and readable. Also keep in mind that PCI DSS is a standard designed only to encourage sensible security practices around the handling of payment card data - it is not a recipe for strong security on its own, so "PCI compliant" doesn't necessarily mean "secure".


What does the last single quote of the sql injection query: ' or "1"="1" ' mean

Think about where the injected string is going. It's being concatenated into a SQL query at a point that is wrapped in string delimiters. String delimiters always need to be paired; if they aren't then the DB engine will detect an unclosed string and reject the query rather than execute it.

An example:

Original SQL "template", before concatenation: SELECT * FROM Users WHERE AccessToken=' + secretParam + ' and you control the content of secretParam.
After concatenation with a real secret, like DEADBEEF: SELECT * FROM Users WHERE AccessToken='DEADBEEF'; this is a valid SQL query.
When using the "correct" SQL Injection string: SELECT * FROM Users WHERE AccessToken='' or "1"="1" ''. In theory, this will return any user whose access token is an empty string (probably nobody) or for whom 1 equals 1 (everybody, the app will probably just take the first record). In practice, though, the DB might not like the empty string hanging out (the final '') after the second test (the or "1"="1") in the WHERE clause; it'll depend on the DB engine what it does with that.
When using your shorter injection string: SELECT * FROM Users WHERE AccessToken='' or "1"="1" '. Now your query ends with a single quote to open a new string, but not only is this string in an unexpected place, it is never closed. Even a forgiving DB that doesn't mind an unexpected string (perhaps concatenating it with the preceding one) will consider this query to be syntactically invalid and reject it.

There are various other ways of dealing with this, especially for DBs that won't tolerate an unexpected string. You can incorporate the quotes in the template to do what you expect, using an injection like ' OR ''=', which would produce SELECT * FROM Users WHERE AccessToken='' OR ''=''; this has the same effect as above (swapping a test of whether the string "1" is itself for whether the empty string is itself) but leaves no dangling apostrophes/quotes or unexpected strings. It's also nice if there are additional tests or clauses after the insertion point, and you want them to be processed correctly.

Alternatively, you can terminate the query after your insertion. For example, many DB engines use -- (two hyphens) as a single-line start-of-comment indicator, similar to // in languages such as C or JavaScript, or # in shell scripts, Python, etc. Thus, you can make your attack string ' or "1"="1" -- and the generated SQL would be SELECT * FROM Users WHERE AccessToken='' or "1"="1" --'; this is a valid SQL statement containing two tests in its WHERE clause, and a single-character comment of ' at the end of the query. That's especially helpful of the query contained additional clauses or restrictions that you wanted to get rid of.


Missing DEK-Info header when converting from P12 to PEM using OpenSSL 2.8.3

That's not any version of OpenSSL. LibreSSL is a fork of OpenSSL and has its own version numbering and history that is now separate from OpenSSL, although it continues to use the same external interfaces including the program name. However, the fork started from OpenSSL 1.0.2-something, which is greater than 1.0.0, and in all OpenSSL versions from 1.0.0 in 2010 up pkcs12 (import) writes the privatekey in 'new' (2000!) PKCS8 formats rather than the 'legacy' or 'traditional' formats from about 1990, which is what your software apparently wants.

In OpenSSL you can use the rsa subcommand to write a traditional-format file:

openssl rsa <p8file >oldfile -des3 # or other supported -$cipher

I can't guarantee LibreSSL retained this functionality, but it's worth a try.

FYI the encryption, or more specifically the password-based key derivation, used in traditional-format files is extremely weak. Unless you use a very strong password -- i.e. one strong enough a normal human can't rememeber it -- this file can probably be broken by an adversary who gets their hands on it. That's why PKCS8 is preferable and it was used at the first opportunity for an incompatible change. This has been asked and answered dozens of times on security.SX and/or crypto.SX; if interested searching for EVP_BytesToKey should find you many of them and links to more. (This issue also affects the enc subcommand, possibly excepting version 1.1.1, so you may need to skip over questions about that.)


How secure is XMPP with self-signed SSL certificates?

Self-signed certificates are just as good as certificates signed by another entity. The only thing that they're not is in the Public Key Infrastructure. Every modern computer comes with a list of known, trusted root certificates. Any certificate signed by one of these trusted roots is automatically trusted by your computer. Your self-signed certificates are not part of this trust chain, so it's up to you to trust these certificates. Clients will typically prompt you when encountering a certificate which cannot be traced back to a known root, so it's up to you to confirm that prompt.

The problem in this is that if you confirm this prompt every time by hand, it's very easy to be compromised by a man in the middle, since human verification of a certificate is very error prone. So you will have to establish trust in your self-signed certificate once initially and then let your client handle it. How to do this depends on the client and platform, but most/all platforms have some way of adding arbitrary certificates to the trusted certificate store.


Security policy for system administrators

Alright, so this was originally intended as a comment to your response to the answer given by @jl01 but it became too long and it should have merit on it's own....

There's almost an art to creating policies.  Ideally (though i'm sure some people would disagree with me) a policy would be a very general statement regarding the topic.  For example, something not much more complex than "This company will operate with current best practices for system patching".  The idea is that a policy should be established and not need changed (if done perfectly).  It should be generalized enough that it will not need to be updated as different technologies, attack vectors, regulations, etc change.

It is very common to split policies up into each separate realm of business/technology.  This lends itself to producing policies that are more custom fitted to your company and allows you to keep clarity when referring to those policies.

Another way to think of it is that a policy is the business' way of covering their hind ends.  It is created to cover as much as possible so if something goes wrong the company can mold their response to each separate situation while still using the same policy.

Those policies would be  expanded on via procedures, guidelines, and regulations (come to think of it, this should be fairly close to how SANs describes it). I believe SANs refers to what I call "procedures" as "standards".  I apologize for any confusion because of that.

A procedure would be an actual practice which follows a policy (many policies that i have seen seem to refer to the applicable procedures within the policy itself).

A guideline on the other-hand is exactly that, a suggestion of acceptable practices.  Though they are only suggestions, they are not to be taken lightly.  When audits occur, these are the low hanging fruit that an auditor can latch onto.

Procedures and guidelines are the only things that you should need to update with changing business climate, environmental issues, threats, etc.

When i designed my first set of policies, granted this was from a class regarding information security policies, I set up these different policies:

Information Sensitivity Policy
Extranet Policy
Email Policy
Removable Media Policy
Password Policy
Security Monitoring Policy
Router Security Policy
Server Security Policy
System Update Policy
ASP Policy
Server Management Policy
Security Training Policy

This is not an exhaustive list, but it should give you an idea of some of the break downs that may take place.  The way policies are divided are dependent on the needs of that company.

Last, but definitely not least, each policy should be created in such a way that there is do doubt as to what and how it's applied.  By this, i mean that along with each policy the purpose, the scope, the enforcement, and the definitions regarding that policy should be established. I always have fun typing the phrase "will be subject to repercussions up to and including termination".

Though I did not list it earlier, an ethics policy should be in every policy set.  Even when using ASPs, or any service for that matter, it's good practice to request their ethics policy and, depending on what you see, require by contract that they abide by your companies ethics policy for that job.

So, i may have dove a bit too far into the subject... but i hope it helped.

Disclaimer: I am more than aware that this isn't the only way policies can be constructed.  From my experience, most companies have a set of policies that have been loosely constructed over years of regulation changes and compliance issues.

p.s. an ASP is an application service provider, i see that i haven't mentioned it's definition anywhere above.


"Classified Information" means that the information is sensitive and requires a security clearance to view.

"Unclassified Information" is the opposite: information which is not considered sensitive and may be made available to anyone.

Marking an information explicitly as "unclassified" makes clear that it was evaluated and deemed harmless. When a document is not marked yet, it was not yet evaluated for which classification applies to it. That means the person handling it can not be sure how confidential it really is and should assume that it is confidential.


What kind of encryption is a one-time pad?

It is not a substitution cipher.  Schneier classifies it as a stream cipher because it converts plaintext to ciphertext one bit or byte at a time, generally by XORing the plaintext with a "keystream".

In most stream ciphers the keystream is only pseudo-random, but in a classic "one-time pad" the keystream is entirely random.  It can be though of as a fresh key for each message, equal in length to the plaintext, which is typically combined with the plaintext via XOR so it is easy to get plaintext back from the ciphertext with another XOR.  The trick is getting the pad itself - good quality truly random keying material - to the other end of the communications channel, out-of-band....

See also One-time pad - Wikipedia, the free encyclopedia


However, the server must store some form of the mailbox password so that the user can be authenticated. Should a security breach occur on the server, wouldn't it be just a matter of time for a determined hacker (and a powerful hacker, if, say, a government decides to be one) to figure out the real mailbox password?

Security is about trade-offs. It is sometimes said that the only secure computer is the one that is unplugged from any power source, locked in a safe, sealed in concrete, sitting at the bottom of the Mariana Trench. I would probably add that it must have no device within it capable of storing any information. Such a computer would be (relatively) secure, but it would not be very user friendly, easy to use, or particularly useful for any real-world purpose. Anything more useful than this must trade some degree of security for its usability.

Now, having said that, the question remains: can we mitigate reasonable threats? It turns out that yes, we actually can.

Modern cryptographic algorithms (primitives) are very resistant to attacks. Even SHA1, which is currently being sunset for being weaker than expected (also from Google) is still more than strong enough for most use cases; it is being sunset because it turned out to be not as strong as we believed it was for this particular specific use case. This doesn't mean SHA-1 is broken; it simply means we have reason to switch to something even stronger.

At least in the public, we currently have no idea how we would even approach attacking AES-256 (assuming it is implemented correctly) successfully, given only a ciphertext/plaintext pair (a "key recovery" or "brute force" attack). Wikipedia gives the best publicly known key recovery attack of AES-256 at 2^254.4 complexity, and even that is with ridiculous amounts of data available. That cuts the time by about one third to two thirds (2^-0.6 ~ 0.6596, 2^-1.6 ~ 0.3299; remember that on average, the work factor to break a n-bit key by brute force is 2^(n-1) because with a randomly picked key, you will on average have found it after searching half the key space, with possibilities ranging from finding it on the first try to finding it after testing every single key in the key space), which means an attack that we thought should take utterly totally completely exponentially longer than the life time of the universe now only takes utterly totally almost exponentially longer than the life time of the universe. The difference of 0.6 or even 1.6 bits of security is totally insignificant in practice, and likely overshadowed by any issues in the random-number generation in the session or persistent key generation stage. We can't even realistically count to 2^128 in a reasonable amount of time, let alone do anything useful with the counted value, and 2^256 is another 2^128 times more difficult.

Even if the entity trying to break the encryption has access to a quantum computer, Grover's algorithm only reduces the search time (in terms of elementary operations) from approximately O(2^(n-1)) to approximately O(2^(n/2)), which means that a 256-bit key gives you the same effective security against a quantum capable adversary as a 128-bit key gives you against a classical attacker. This has actually become a major argument for 256-bit keys in symmetric cryptography; against a classical attacker, for all practical purposes, as illustrated, 128 bits is enough to provide a quite good level of security, but using 256 bits of key provides a safety net should quantum computers turn out to be viable on a larger scale. (Note that this is about the symmetric cryptography, not the key exchange! Many asymmetric encryption algorithms, including RSA, would be utterly devastated by for example Shor's algorithm in the face of a viable, large-scale, general-purpose quantum computer.) This is a major driver for work towards what has been termed post-quantum cryptography.

The probability that you are using a password that provides anywhere near 256 bits of entropy is basically zero. For comparison, you'd need a 20-word properly generated Diceware passphrase to get 258 bits of entropy, corresponding to 100 rolls of a perfectly fair six-sided dice; correct horse battery staple would get you only 52 bits of entropy if it were a properly generated Diceware passphrase and not publicly known (it, and probably every permutation of it, is almost certainly in every password dictionary on the planet by now), which at a trillion guesses per second (about 2^40 guesses/second) would last 2^11 to 2^12 seconds or on the order of one hour. That is nothing more than a minor inconvenience to the attacker. However, there is nothing preventing you from using a high-entropy password. ProtonMail does not appear to impose any arbitrary restrictions on password length, so if you want to, you are free to generate and use a 20-25 word Diceware passphrase for security matching that theoretically obtainable by AES-256.

As Lucas pointed out by incorporating the XKCD comic "Security", chances are that an attacker wouldn't be attacking the cryptographic primitives; they would be going after something else. It doesn't have to involve hitting you with a wrench; it could be something as mundane as remotely breaking into your computer, or breaking into your home (perhaps to install a physical key logger, or to try to get their hands on information that will help them bypass the encryption such as unprotected copies or written-down passwords), or getting their hands on shipments to you and doing interesting things with them that you would not agree with, or remotely listening in to the emissions caused by your computer during normal operations, or compelling you to cooperate through some form of blackmail or other power posturing. Because let's make something very clear: if the government is targetting you specifically, and aren't bothered by taking actions that show this, then they will find a way to extract what they need. The saving grace in a way is that most people are not specifically targetted and/or are not worth that level of exposure, but are simply caught up in the dragnet surveillance. (Though if a government-level adversary does later realize that they are interested in you specifically, that does make it easier for them to go back and look at older communications, possibly finding something incriminating there as well. When you can't know whether or not you are being targetted or what they might have if they choose to target you later, that becomes a problem.)

There are also ways of ensuring that someone knows a password without actually having the password stored in any recoverable form. Keyed hashes (HMACs) based in part on the password, zero-knowledge proofs, or simply calculating a cryptographic hash over a given random plaintext and storing only the encrypted plaintext and hash (if the encryption key is related to the password, then the two can only be recovered as a matching pair if the password is correct), are all ways this could be accomplished.

There are ways to slow attackers down. Encryption algorithms like Blowfish accomplish this by having a complicated (and slow) key schedule, or we can use a slow-running key derivation function such as properly tuned PBKDF2, bcrypt, scrypt or others with algorithms with less complex key schedules (such as AES). The idea here is to make attacking the (relatively low-entropy) password nearly as difficult as attacking the encryption key directly, while keeping the performance penalty of the conversion from the password to the encryption key small enough to not bother a human who is using the service. If the KDF is turned all the way up to eleven, this can make attacking a reasonable-entropy password quite impractical without inconveniencing a human user very much. (You probably basically wouldn't notice a 500-1000 ms delay when logging in, but if every tried password takes half a second normally, even with highly optimized implementations or large amounts of powerful hardware this puts a major dent in how many passwords can be tried even in an offline attack in a given period of time.)

While none of this is necessarily how ProtonMail specifically have solved the problem, I hope that with the above I show that, while the problem exists in theory, it is also very much a problem that is perfectly solvable in practice. Any competently written cryptographic software is going to employ a mixture of these techniques, as well as others.


Why doesn't Outlook handle phishing URLs

Wow, lots in that question to try and get through.

First, what might you be missing? I'd suggest two things from experience. Firstly, the client PC's should only run whitelisted applications, everything else should be blocked. This cancels out masses of malware.

Second, kill off access to all known advert servers, malware sources and command and control (C3) servers - at the Router/Firewall level. You can obtain lists to support this if you like but most people use a smart filtering server such as those from Sophos and others. I even have a script that does this for my home Ubiquiti router - brilliant. This kills off many malware risks and drive-by attacks from rogue adverts. It will also protect from some, at least, of those nasty links.

Next, the unwritten question: Why is Outlook rubbish and other clients not a lot better? This puzzles me as well. With all the advances in UX, information theory and our understanding of thought, you would think that we would have a vastly better core written communications system by now. All I can think of is that email and related comms technologies are seriously uncool to developers. So they get badly ignored.

Now the specifics:

Do you mean something like Intranet Home Page? I think that you might find that cropping up a fair bit in legitimate HTML formatted emails. As found in enterprises large and small everywhere.
Two issues here.

Firstly, your email server should do that, don't leave it to the client.

Secondly, there are cases where this is used (though whether legitimately is perhaps arguable). External systems sending email as a corporate email is the typical case. Some cloud based mailing lists used internally, scan to email systems sometimes. All of these are regularly seen spoofing from addresses. Not really good practice but still far too commonly used.
Because a) the words you list are valid words for many organisations and b) because this too should be done by the server not the client. Check out the open source Spamassassin for example.

This is not a simple task though and you have to try and be clever about combinations of words and other markers - this is a soft scoring thing not a definite identification - one persons junk is anothers legitimate email. Of course, the bad guys have access to the same tools and adapt accordingly.

DLP is about data leakage rather than spam/maware discovery. There are client side tools that do this and Outlook's own junk discovery process makes a ham-fisted attempt. You will need 3rd party tools though to do it properly.
Well this is certainly theoretically possible since that is what happens in Outlooks junk folder. No idea why this isn't an option for everywhere else though.

However, Outlook is meant to be an enterprise email tool and actually most enterprises rightly make use of HTML emails in order to avoid people constantly sending one-page Word documents (AKA "memos") to each other like in the 19th C. So again, there has to be a balance - not saying the balance is right, just pointing it out.
Once again, this is not the experience of many large enterprise users that are the mainstay of Outlook customers. I constantly get emails with attachments from people not in my immediate contact list.

It wouldn't be that hard to adjust your server-based spam-checking service though to include this as a rule.

Trust me though, I hear your cry of despair. I find that the higher up the organisation chain you get, the more likely someone is to fall foul of malware/phishing links too!

We've had good results though with a constant drip feed of reminders and warnings. Making sure you always do a fairly intrusive extra "virus scan" using an engineer at the desk (or remotely) also helps drive the message home even if you know one isn't really needed. ;)

It is also good to do a deal with your senior execs then do some internal phishing exercises - after warning everyone that you are going to. If you can catch someone senior out, try to see if they are brave enough to be used as an example. In any case, publish some results and repeat a few months later.


can I find on which machine was a zipped archive created?

NTFS can mark files with "zone information" in a hidden stream associated with the file.  If the file was created in a different zone (as defined in IE zones) then it's possible that the IE + windows explorer integration present in windows may be of interest to you.

I'm not sure if 1) that zone information contains information about the source machine, or 2) if that zone information was recovered from your undelete utility

I haven't personally explored this detail of zone information beyond this but would appreciate it if you share your learnings.


If they have the real old password in the field you can retrieve it by looking at the source of the HTML page. But usually there is only a placeholder like "this was the old password" which is used to detect if the user changes the password or if something else inside the formular gets changed. With proper security the site cannot even put the old password into the form since the clear text password itself should not be known to the site because the password was stored in an irreversible way (see how your passwords are stored on the internet..).


Is my custom password hashing algorithm insecure?

For starters you rolled your own piece of password hashing algorithm. There are currently but three password hashing algorithms which are considered secure:

PBKDF2
scrypt
bcrypt

You are iterating and you are appending a salt. You also seem to add the username within the algorithm, which does not add any benefit as you are already using a salt.

What I can't deduct from your code and which is very important is the length of your salt and how you generate it. A salt should never be hardcoded, but secure randomly generated when hashing the password. The salt should be unique within the database and preferably globally unique as to avoid identification of similar passwords in different databases (hence a username is not considered a good salt).

Also the way PBKDF2 works (which leans closest to your implementation) is by using a HMAC where the random generated salt is the key used to calculate the message digest, rather than appending everything together. PHP's password_hash is using the bcrypt algorithm.

So to summarize what you gain by using a standard algorithm instead of your own:

You will generate random salts
You will use a standardized and secure password hashing algorithm


Encrypted data embedded in JPG and Other file types

I think you're on the right track.

The best you can do is to attempt to identify the information as a specific type, and this is what you've begun doing. Sometimes this is easy, other times it's not possible and you need to brute force guess different potential formats.

Along these lines:

You're correct about the hash guess
You're correct about the base64 encoded 'Salted__' being the identifier for openssl encrypted output. The next 8 bytes are typically the salt, and then after that the encrypted data

So you've been given some hints on the format of the encrypted data and a couple of strings that look like passwords of some sort. I think you're now at the brute force part of the puzzle.

Specific to reversing hashes: I'd suggest putting it into google as a first attempt to finding the pre-hash value. Google is a fantastic tool for this.

Good luck!


Will virus downloaded to guest OS affect Host OS?

If the VM connected with a bridged connection it could possibly spread via the local area
network if the virus has any autospread features or exploits that could target your host OS.

If you had shared folders with the guest os you could also be infected.

Your best bet is running the VM in an isolated network.


Maybe try using some alternative expressions to a query that checks whether 1=1? Some examples could be:

For instances when the 'OR' keyword is being caught by WAF:

1 && 1 = 1

1 || 1=1

For instances where the equlals sign (=) is being caught by WAF:

OR 2 between 3 and 1

or 2 > 1

or 1 < 2

For instances where integer-based comparison is triggering WAF:

OR 'lolol' = 'lol'+'ol'

OR 'LOL' > 'L'

OR 'LOL' = N'LOL'

I've never personally used DVWA (although I did go to university with Ryan Dewhurst, lol..) but these are just a few examples that come to mind. They're performing the same check as 1=1, just via alternative methods.


How do I ensure that a VPS host will keep my information private?

Legal documents.

More specifically, the Terms & Conditions you agreed to when renting a VPS from a provider.


Is it more secure to specify https:// in front of a domain?

Would I then request an insecure connection (http), get redirected to
  the secure https protocol by the http response, and thus making a less
  secure request?

It depends.
In all generality the answer is yes, you are making an insecure HTTP request first and then the server tells you (hopefully with a 301 response) that you should use the HTTPS site instead and the browser loads that one. Of course, on the first insecure request anything could happen, including you being served a fake website. However there are (at least) three exceptions to this rule, which will make the browser look up the HTTPS version directly.  So let's go through them!

301 Redirect Caching. 301 is the HTTP status code for "permanently moved" and some browsers are caching this response and don't even try to request the old site anymore but send you straight to the new one, for performance reasons and in this case a HTTP to HTTPS redirect  would also profit from this.
Browser Add-Ons. There are browser add-ons which keep a database of domains supporting HTTPS (somewhat) and if you request data from any of these domains, the add-on will automatically re-write the request to ask for the HTTPS version of the site. HTTPS Everywhere famously does this and covers a wide range of websites which don't deem their HTTPS "production-ready" (such as Stackexchange prior to March 2017).
HTTP Strict Transport Security (HSTS). This is flag in the HTTP response header which states that the site (and optionally all its sub-domains) may only be accessed using HTTPS during the next specified days without exception. This way, when you request a known HSTS domain, the browser will directly convert the HTTP request to a HTTPS request automatically. As a bonus, you can register for HSTS pre-loading for your site with the browser vendors and then the browsers will come with your HSTS entry pre-equipped starting with the next update. Stackexchange has HSTS deployed without pre-loading (on most sites).


How to choose Chrome extensions with security in mind

Is there a way to install an extension without actually granting everything it wants?

Only for optional permissions, but "Read and change all information on all websites you visit" is usually required.

  Is there a database of trusted extensions that underwent rigorous auditing? Other ways to identify them?

No, at least none that are advertised by Google.

  Any specific protocol I should follow when choosing and installing an extension to ensure security?

"Read and change all information on all websites you visit" is actually common. If it requires other permissions, such as "Capture content of your screen", then you should be more worried. There are some more here:
https://developer.chrome.com/apps/permission_warnings

Make sure that the permissions make sense for the extension. Reading all website data probably doesn't make sense for a new tab page. Reading the code is always best.

  Are there extensions that are endorsed by Google and have their seal of approval? How to identify them?

Some extensions are published by Google. Those are the only ones they endorse.


OpenSSL encrypting small packets bandwidth overhead

- Hello, this is TastyChef hotline, how may I help you ?

- Hello. I am cooking. I need to know how long I should put my food in the oven.

- It depends on what you are cooking, Sir.

- Oh, it is a Miele-Samsung 1200+ oven. Serial number is X67NQ-56D3034.

- Not the oven, Sir.

- Do you think replacing the oven with a 1500+ would change the cooking time ?

- ...

What matters is the protocol you are using, which boils down to the involved algorithms and encoding formats. You have to understand what you are trying to do. Right now, you appear to "use OpenSSL" as a kind of cryptographic seasoning, in the wild hope that sprinkling encryption about will make security somehow happen. It does not happen that way.

They say that software engineering begins with architecture, then analysis, then specification, then (and only then) implementation. If you skip the first three steps, then the fourth will lead to doom.


A lot of analysis tools look for known data structures (i.e., patterns) in memory that indicate a particular type of information.

For instance, malloc'd memory has header (and sometimes trailer) data that point forward and backward in memory to adjacent memory. Free'd memory pointers can jump around in memory if they aren't consolidated/coalesced.

Windows C++ applications have the notion of classes and a "this" pointer, which points to a class. The structure of C++ classes is known, so when one of these pointers is found a lot of information about the class can be derived. If it is a known class/data-type then it can be parsed relatively easily.

File's open in memory can be discovered by their "file signatures" (usually the first 3 or so bytes of the file). If those are found, some quick analysis can be done to determine if it's actually a legitimate file of that type or if it was dumb luck that those bytes occurred.

So, in general, many memory analysis tools look for known patterns in memory and/or hook into key datastructures within the kernel and then parse memory from there. Once you find code areas, you can "disassemble" them and find references (pointers) to other regions of memory. And following those you can find other data structures.

I hope that helps some.


Computer name naming convention for security

You have identified only one risk, that of an attacker identifying machine roles on the network by using predictable host names.

I think you missed the competing risk, that of increased operator error by not using predictable and descriptive host names.

This is how I would assess those conflicting measures:

Use unpredictable host names

Benefit(s)

An attacker will need to spend (significant) more effort in determining the layout of your network and to identify the most profitable targets for a penetration attempt.

Risks

Operator error. Users and administrators may have difficulty identifying systems  and their correct roles e.g. confusing test and production systems.

Probability: high
Impact: high

Rationale: Most humans have terrible memories where "random" data is concerned --> high probability.

Also there are usually very few barriers that prevent trusted users and administrators from making high impact mistakes  --> high impact.

Use predictable host names

Benefit(s)

Reduced operator error rates, ease of management and automation.

Risks

Attackers will  also have an easier time determining the layout of your network and to identify the most profitable targets for a penetration attempt.

Probability: medium
Impact: low

Rationale: Not every naming convention is immediately intuitive to a black-hat  attacker --> medium probability.

Also using hostnames to predict a network layout is only a shortcut, but doesn't provide information that an attacker wouldn't be able to learn through other means.  And  knowledge of the role of a server as disclosed by a hostname does not automatically make it more vulnerable (only more or less valuable). --> low impact.


Ability to get a MAC address and IPv6 through proxy servers

First and foremost, understand what a MAC (Media Access Control) address is and IP (Internet Protocol).

A MAC (semi-unique but not really) is an identifier for your network card to talk with it's local network at a level lower than Internet Protocol. Typically this is an ethernet packet along the lines of:

      | MAC | Flags | Payload_1 |

Inside the payload is your IP protocol.

As soon as the ethernet packet hits your local router or access point, everything except payload_1 is stripped away for connection to the next router up the line, becoming:

     | controls | Source address | Destination address | Payload_2 |

The MAC is gone, it's not part of Internet protocol! The only MAC the web site can get is his own router connection, yours is long gone.

As far as your IP, if you are using Tor or a functional anonymizing VPN, that's been changed as well by the time it hits the web server.

One odd exception is an obscure IPv6 auto configuration mode that computes an IPv6 address from your Mac. This can be reversed back to a MAC. Even if the Mac were obtained this way, at most it identifies the network card type (such as Netgear) and a number that may or may not be a real identifier that is not directly traceable.


How to stop quick access from saving encrypted folders?

I found the documentation for this Issue and it basically says, to be save you have to use a hidden Operating system when mounting your volume.

https://veracrypt.codeplex.com/wikipage?title=Security%20Requirements%20for%20Hidden%20Volumes


Best practices for managing AWS EC2 Key Pairs

Regarding the general managment of private/public keys, there are already other answered questions here on SE: What is the best practice: separate ssh-key per host and user VS one ssh-key for all hosts? and What's the common pragmatic strategy for managing key pairs?

Regarding AWS specific details: you can and should create your own key pairs outside of AWS and upload the public keys to Amazon. You can find the documentation for creating your own keys for both Linux and Windows systems in the Amazon EC2 documentation. Just make sure that you use the correct format for the key (the text you paste into the key upload form should start with ssh-rsa).

If you have added additional keys, you can select them when launching a new instance. You can also add them manually lateron (for Linux systems: add the public key to the ~/.ssh/authorized_keys file).

Edited: You should follow the advice given by @Jedi in the comments to your question:

  Private keys should be private to the user. Users should have their own keys and accounts both for personalization and auditability.

Not only for personalization and accountability, but also with regard to key revocation when somedody leaves the team / a key pair is compromised.


How secure it is to identify a user by an sms's caller id?

It can be faked.

https://en.wikipedia.org/wiki/SMS_spoofing

If you want to validate a phone, you should make sure they get what you send rather than trusting they are who they say they are.


This is a huge question but I'll put out a few things in the way I would approach finding other targets to pivot to.

1.) look at layer 2 arp -a sends no packets to the wire and helps you spot other hosts the system you have access to is talking too.

2.) look at layer 3/4 lsof -i (or it's equivalent) will show you established connections that allow you to see the IP's and some protocols that this computer is communicating with others on. Again this sends no packets on the network.

3.) Check for mounted storage, local scripts, backup configurations, DLP software, or passwords which may be configured to give you information, or possibly access too, other servers. Again this sends no packets onto the network and the storage devices may have shared networks to other hosts (possibly beyond the scope of your question).

4.) At this point verify you are not on a HoneyPot before proceeding.

5.) Optionally at this point you could look at packet capture, this can be detected but 99.9% of organizations aren't looking for this so it's generally safe to do. This will help you find other hosts on the network that are broadcasting their information and depending on the type network may give you access to lots of other traffic nearby.

6.) Determine internal DNS and if possible scan the internal DNS for other hosts. DNS traffic is considered pretty normal. Do it slowly if you are in a high-security environment.

7.) At this point I would suggest exploiting the connected systems using the connecting protocols. You want to go out on protocols the system you are on normally talks out on (DLP, NMS, Backup are most common but frequently databases are also available). These are outbound connections which might not look weird to from the standpoint of netflow communications. If you can pivot in-band it is much stealthier than scanning.

8.) Next step connecting to hosts which connect to the one you are on. This is similar to the step above but from a netflow perspective some systems always initiate connections to the end points in this case you are likely an endpoint connecting back which may or may not get caught.

9.) If that hasn't worked you start scanning. Slow your scans below the most common IDS timing threshold for scans or do this manually at first. Aim for protocols you can exploit and prioritize most common protocols that a given client would have. Go slow stay under the radar. The scanning tool nmap from nmap.org has a --top-ports option if you don't know where to start. I'd say start with the top 10-20 ports at first unless you are in a rush.

10.) If you are still having no luck now you start deeper scans and map the entire environment out.

11.) Still having issues try jumping VLANS's

https://github.com/nccgroup/vlan-hopping

Good video of it in use on a Cisco switch.

https://www.youtube.com/watch?v=2Y7CQDkY8nE

http://www.yersinia.net/attacks.htm

https://github.com/rapid7/metasploit-framework

12.) Check for wireless, if the device you have has wireless access (try turning it on at some point if it's not on) scan the wireless network for other targets. Don't forget Bluetooth or any other protocol likely to be on the type host you have access too.

13.) Still no luck. Check to see if you are on a Virtual Machine, identify which one and look for ways to jailbreak the VM into the Hypervisor and attack from there.

NOTE: Always check for IPv6 connections and explore for storage connections in depth. There is also more work to be done on the local host like grabbing keys and passwords if you can but your question was more focused on finding targets so I'm leaving that out of scope.

This is a BIG subject with lots of additional things you could do but what is a listed above is a very effective strategy for mapping out nearby hosts in the situation you asked about.


When moving beyond SSL3 is not possible, what cipher suites are immune to POODLE?

I don't think so, at least not with IE (per this page on Wikipedia).

Between RC4 and CBC there really aren't any good SSLv3 cipher suites to use.


Should expired compromised certificates be taken care of if the time is always correct?

From RFC 5280 3.3 Revocation

  An entry MUST NOT be removed
     from the CRL until it appears on one regularly scheduled CRL issued
     beyond the revoked certificate's validity period.

If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which might not be handled by some applications).

Your server should always have the correct time. It's your server that should check the validity of the certificate not the web client.


Safe way to backup Bitcoin hardware wallet

There are other risks, for example your hardware may be compromised. Purism attempts to mitigate the vulnerabilities popping up in intel chips as just one example, but do they succeed? Hard to say, intel chips are not open hardware. The idea of chips that can be remotely exploited when your computer is 'turned off' is kinda scary, but I'd caution this is only one example.
https://puri.sm/learn/avoiding-intel-amt/

One thing hardware wallets attempt to do is to mitigate risk of malicious hardware (other than the wallet itself of course), so just be aware that trusting your key to other hardware extends your trust also to that other feature rich, and thus target rich software AND hardware stack. Whether that risk is ok or not is of course a judgement call.

There is another approach I've been tempted by, but BIP 39's use of SHA-256 for a checksum gets in the way. I'll ask Trezor if they could add optional hex bypass (sans checksum) to BIP 39 during recovery, for advanced users.
http://ben.mord.io/2017/11/paper-pencil-seed-generation-from.html


What's the importance of sshd's setting RekeyLimit?

The idea behind rekeying is that session keys may be susceptible to some unspecified attack, such as direct cryptanalysis or side-channel attack. A common theme in most attacks is that they require the analysis of a large amount of encrypted data to execute. By limiting the amount of data transmitted with a single session key, you can effectively thwart a large portion of attacks against your encryption keys, whatever those attacks may be.

The cipher and chaining method you use does have an affect the type and effectiveness of attack an adversary might deploy. But the defense of rotating your session key after a few GB is a reasonably effective mitigation strategy.


How does a merger formally impact an ISO 27001 certification?

You are right with answer 1. The certification is always only for a specific scope. I know many companies which only certify some branches and still put the certificate on their website.

There is no automatic invalidation. The certification can be revoked after the yearly check but usually only if major flaws are detected. Most of the time you will get several months to fix the issue, and during this time you still hold the certification. If you, however, fail to improve during that time you will have to re-certify.

Changes in processes are completely normal and have to be treated as described in ISO 27001.


It seems that someone remotely logged into one of your 2FA-authenticated devices and accessed your received email while your token was still valid.

Either way, it's unfortunate you have to deal with it.

Maybe implement a protocol of always logging out of the browser at least on the PC's and use a password generator to copy/paste your new password just in case there is a keylogger.


Things to do to ensure that data is secured on my virtual server

You could start by reading about some (Ubuntu specific) best practices. Like:

Closing unnecessary ports.
Removing unnecessary packages.
Setting up some basic iptables rules.
Setting up a Web Application Firewall like mod_security.
Look into DNS solutions like CloudFlare to prevent heavy load on your VPS processes in case of DDoS-attacks.
Working with SSH keys and/or setting up a two factor authentication method like Authy-SSH.
Setting up downtime-monitoring like Pingdom or UptimeRobot.
Do some software specific security hardening for example for Apache, PHP and MySQL.
Get regularly tested by the use of Vulnerability scanners and/or penetration testers.

It's important to regularly update all software packages and the Ubuntu kernel and you can take a look into full disk encryption with LVM/LUKS.

Also I recommend to take a look at http://hardenubuntu.com/ like user PolymathMonkey suggested.


Envelope Encryption with asymmetric keys vs KMS

It's all about where you store the secret and who has access to it.

First a clarification: You are confused. KMS does not use asymmetric encryption (also called Public-Key encryption).  It uses private key encryption to enable envelope encryption.  They are two different things.

In asymmetric encryption the producer of the encryption never has to access the secret, they just need the public key.  The producer uses the public key to encrypt, the consumer uses the corresponding private key to decrypt.  In order to facilitate key rotation the producer sometimes appends the public key that was used to encrypt so that the consumer knows what private key to use to decrypt.
No matter how much data is encrypted there are no hints at the private key.  The algorithm for decryption is usually more compute intensive than private key encryption.

In envelope encryption the producer and the consumer must be the same (or both have access to the master key). You use a master key to generate a secondary key called a data key.  You then encrypt the data key using the master key and the data itself using the data key, then you append the encrypted data key to the encrypted data.  When you decrypt you use the master key to decrypt the appended data key, then use the decrypted data key to decrypt the data.

The advantage of this is that you can cost effectively store your master key in purpose-built Hardware Security Module and never expose it to anything else without having to pass all the data you encrypt into the HSM.  You can even generate the key inside the HSM and not take it out so that there's no chance that it has ever been exposed to anything externally.  KMS provides you with a cloud based HSM and it's backed by physical HSMs at Amazon.

If you don't care about keeping your master key in an HSM, then you can do the same kind of encryption using your own key that you try to keep safe by putting in on a jump server or something like that.  Also as long as you aren't encrypting more than 250 million TB you can skip the envelope.

If you're looking for some example code you can snatch up to implement either simple AES encryption or envelope encryption you might want to check our open-source project.  It's got an implementation for each you can leverage...

https://github.com/kunai-consulting/KeyStor


I don't understand completely the scenario, could you provide a simple ASCII diagram?

Anyway, I don't really like the idea of giving E to the user since it will be a very hard password to remember, maybe you can do it in the other way, give K to the user (so you can choose it) and store E in the server.

I will edit my response after the scenario clarification :)


Hacking Windows Box via Directory Traversal

I would look at the source of the web app to hopefully find additional vulnerabilities or credentials. For example, you might be able to find a SQL injection by reading the code, or you might be able to find a web.config file containing database credentials.


Should have a look at this:

https://vaultproject.io/docs/secrets/ssh/index.html

Basically Vault (note the answer time) can create one time credential for people to use for SSH.

Most of its security back ends are focused on one time or short lease credentials which keeps rotating, and Vault becomes the central token vending machine.


EDIT:

  Cross-Site Flashing occurs when user controlled data is not validated
  and used in one of the following functions or variables:

loadVariables
loadMovie
getURL
loadMovie
loadMovieNum
FScrollPane.loadScrollContent
Sound.loadSound
NetStream.play
flash.external.ExternalInterface.call
htmlText

  In other words, this means that the Flash application must reference
  external URLs, and the locations of those URLs are set through user
  defined parameters (usually Flash Vars).

  In order for this vulnerability to be successfully exploited the
  victim needs to click on a specially crafted link created by the
  attacker that will use the vulnerable Flash application in order to,
  for example, steal users' credentials.

Even if Flash scripts have restrictions due to the same-origin policy (for Flash you can read its details on here)  Flash is a vector for XSS attacks.
For such vulnerabilities, you do not need necessarily entries for users as on this demo or as on this website that manages a huge database and entirely built in Flash Player.
You can find several real world examples of such XSF attacks on here.
I think the simplest and best tutorial about XSF attacks is this one.


Yes, it's possible because of the limited length, but it has a very little chance.
Read a bit about hash collision, for example: http://preshing.com/20110504/hash-collision-probabilities/


Question about potential ISO infection and ISO verification

No, a virus cannot infect your file while downloading.

The GPG key means that the ISO is as intended. There is a chance that the ISO was infected and Unbutu didn't know.

Yes, the hashes would be different. That's why they are used.


When should I not use CSRF protection for a form?

Yes, using tokens is the only way to protect reliably against CSRF attacks.

Whether a protection is required or not depends on the actions the program does with the submitted data.

As a rule of thumb: If data is modified with the permissions or context of the current user, you need the protection.

If no modifications take place, it may be okay to not protect. A common example are search forms and results. Please note that logging which searches are done by which user is a kind of modification and therefore the form needs to be protected.


Endpoint for checking if user exists in system

Yes - you should worry about this.

Email addresses are personal information; they are linked to an individual. As G-Man mentions, there is a spam risk in divulging what email addresses exist. But moreover, the fact that a particular person uses your site is private information, that you should not disclose publicly. All sorts of sites could potentially be embarrassing: porn is an obvious one, and a recruitment site could be too. You haven't told us what your site does; but even if it's something quite innocuous, the fact that a particular individual is a member is private information.


This is very complicated. You can have all sorts of recipes for hiding your IP but everything depends on the willingness and capacity of your target to go after you.

The story of the fall of Silk Road's owner (Ross William Ulbricht) is a prime example of things which can go wrong when trying to hide.

The "capacity" part is a key point: local authorities for the attack target must have the legal possibility to go after a criminal. The James Bond (or any other well known case you can think of) version is that they can send hords of spies to get you but it is not likely to happen. If the attack comes from a not-so-friendly country then the forensics analysis will provide an information and then hit a wall (the entrance to that country).


The server does sign the ciphersuite. The whole protocol negotiation (covering the ciphersuite, the keys, etc.) is signed. That's the last thing in the handshake: the Finished message. See What stops an attacker from tampering with data sent during the SSL/TLS handshake? and How does SSL/TLS work? for more details.

You note:

  this verification relies on the ciphers negotiated on the handshake, so if the ciphers the attacker chosen were sufficiently weak to break quickly, he may be able to send these confirmation messages as well.

and ask:

  why doesn't the server use its private key to sign its ciphersuite and TLS version (and timestamp of validUntil) so the client can detect downgrade attacks?

Once again, the server does use its private key to sign the ciphersuite and the client does verify it. It happens at the end of the handshake because it can't happen until the client and the server have agreed on what the server's key is and why it should be trusted.

You're worried about an attacker convincing the client to use a weak ciphersuite for which they can forge a signature. Well, there are two cases.

The client knows that the ciphersuite is weak and refuses to use it. Then there's no problem. The client will close the connection.
The client doesn't know that the ciphersuite is weak. Then there's nothing to do. The whole conversation happens with the attacker. The legitimate server is not involved at all. There's no way the legitimate server can protect the client against an attack when the legitimate server does not even participate in the protocol.


What Does Putting Each Subscriber of ISP in One Subnet of His Own Mean?

The "subnet" makes sense only for routing. When machine A decides to send a packet to machine B, it considers B's IP address:

if that IP address is on the same subnet as A, then A thinks that it can send the packet "directly" (A and B are on the same link) and does just that;
otherwise, A sends the packet to its gateway, i.e. a machine G (that A can talk to directly). The gateway is responsible for forwarding the packet to B, or at least to the next gateway in the path from A to B.

As an ISP customer, you expect that all your external traffic goes to the ISP. Having a 255.255.255.0 subnet makes sense only in the following situations:

The ISP does not give you one IP address, but a whooping 255 (since it keeps one for the gateway). This may happen when the ISP provides only private IP addresses, and applies NAT; however, if you got an external IP address, then this is implausible, given the current shortage on IPv4 address,
Customers are really grouped in subnets and their machines can talk to each other directly, without going through the ISP routers. I have seen that in older days (about 15 years ago): a cable provider who had arranged things so that all customers in a single building were really on some LAN-equivalent. It turned out not to be a good idea: some customers were engaging in hostile attacks against other customers, and since they had direct access, the ISP routers could not filter or even detect such behaviour.
A misconfiguration from the ISP. Customers from the "same" subnet are not actually on the same subnet (they cannot talk to each other directly). Consequence is an impossibility of customer-to-customer communications through their public IP addresses in some cases; this is a problem for some applications (namely, some network-aware games).

The third case probably applies here; meaning that what you observe really is an ISP who previously goofed on network configuration, then noticed it and proceeded to fix it. You should rejoice; not all ISP demonstrate that level of competency.


Is it advisable to create a system that stores passwords?

You are right in suspicion that storing all passwords in unencrypted notepad file is a bad idea.

Good news is, systems you seek exist and they are called password managers.

Password managers store passwords in secure way.
They make you remember only login and a master password that gives you access to all the rest.

For your case I'd recommend KeePass. It's open source, free and tested by various security audits.

In company I work for we use KeePassXC, because it's open source, works on windows aswell as linux and supports browser addons that ease access (we use KeePassHelper addon). The addon we use provides 'bonus' layer of defense against phishing sites - as it displays something along like "domain unknown" (which I cannot emphasize enough how helpful it is in my company).

KeePassXC also supports synchronization across devices and can use iCloud, Google Drive or Dropbox as cloud service for password database - but please note that this doesn't mean you share your passwords with Google, Apple or w/e as the the password database is heavily encrypted.

KeePass also has android and iOS apps but since I don't use them, I don't really know how they operate.

Please note that there are other password managers like 1Password, LastPass and recently widely advertised Dashlane. Some of them offer bonus paid features (like synchronization across devices in their cloud) so make research what would suit your company the most.


Malicious php scripts in word press theme folder?

You were most likely compromised through a vulnerable installation or theme, probably through something that is now known and fixed.

First, once you've been compromised a little, it's best to assume you've been compromised a lot and start fresh. Read up on the answers to this question: My server's been hacked EMERGENCY

Second, besides updating to the latest versions, you can take extra steps to help prevent damage when some part of your Wordpress install has a vulnerability. Read up on more from this question:
How can I protect a WordPress installation?


Where/what is the actual HeartBleed bug?

The blog existentialize did a simple, easy to read writeup.

The basics are:

unsigned char *buffer, *bp;
int r;

/* Allocate memory for the response, size is 1 byte
 * message type, plus 2 bytes payload length, plus
 * payload, plus padding
 */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

Allocate what the requestor asked for.  Without zeroing it out.

/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

Copy the sender's payload to send it back to them.

Except... the sender didn't send a payload.

Directly from the blog: "What if the requester didn't actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process."


Mail delivery delay at ``spf=fail``; may that be due to manual inspection and accept?

What is the reason for the delay, and why was the mail accepted and delivered after all ?

It is impossible to tell what has caused the delay since we have no information what software is running on the receiving and sending server, have no access to the log files etc.

One reason for the delay might be Greylisting where mail from yet unknown senders/recipient combinations gets temporary rejected in the hope that a good sender will retry later while a bad sender (spam) will just give up because retrying is too costly. But usually the delay is not that long as in your mail, i.e. maybe 15..60 minutes only.

Of course it can simply be that the server was not reachable, the mailbox was full or similar problems. I very much doubt that this has anything to do with the SPF record because an SPF fail might cause a mail not not be delivered at all but not to be just delivered some hours later.


Why can't the FBI read the key embedded in the iPhone's secure chip/ROM directly from hardware (silicon)?

Yes, it is possible.  However, that runs the risk of destroying the device without getting the data off first, which is undesirable.  It also does not achieve the political goals of forcing Apple to assist in decrypting the device, paving the way with precedent for the flurry of future requests of this sort to come, some of which are certain to have less favorable facts and thus are not as suitable as test cases.


Classification of countermeasures for family of vulnerabilities

I think this might be of your interest
"DeTT&CT aims to assist blue teams using ATT&CK to score and compare data log source quality, visibility coverage, detection coverage and threat actor behaviours. All of which can help, in different ways, to get more resilient against attacks targeting your organisation. The DeTT&CT framework consists of a Python tool, YAML administration files, the DeTT&CT Editor and scoring tables for the different aspects."
https://github.com/rabobank-cdc/DeTTECT


ASP NET Core Identity password reset form prompts for email address

Probably just a usability oversight.

I don't think it has any relation to security as you can just open the reset link if you own the email address it is sent to. So, you know the email address. As you pointed, there is no reason to "protect" this email address and you can just fill it by default in the form which will save the user the trouble of typing it.


Wouldn't transient cookies for session management increase effectiveness of MITM?

Transient cookies are only secure if treated the same way as log in credentials.  Used properly, they should only be exchanged over an HTTPS connection and the cookie should be marked to only be available to an HTTPS connection.  This protects the cookie from a MITM attack.

The cookie is effectively a short term copy of the username and password, so you have to give it the same kind of protection or it becomes insecure.

If the connection is not protected with HTTPS, then it doesn't matter if the MITM grabs the cookie or simply intercepts the request to log out.  If the attacker controls what you can and can't say to the server, you are out of luck.  It might me a slight bit for a passive attacker that can't alter traffic, but the session should also be locked to the IP, so only an active MITM attacker should be able to make use of the cookie and they could also prevent logout.


Generating a secret on a compromised computer

If the machine is compromised - there is nothing that you can introduce to make it harder to capture - they own the box, the memory and the OS.

From what little I understand of Ruby as well the choice of Random is wrong for anything to be secured as it is only a pseudo-random number generator and instead you should be using SecureRandom.

With SecureRandom you won't need to try and find other sources of entropy.


How to crack passwords without revealing them?

I am not a lawyer, and my answer assume that you are in a professional context, meaning that what you are trying to crack testing are professional accounts given by an organization to its employees. As the general security of the organization could be weakened by poor passwords, I think that it can ask its employees to use not too weak passwords. I do not know a technical way to only disclose account with weak passwords without actually disclosing the password, so I would use a more than 2 eyes procedure:

at least 2 persons (a technical admin and a senior manager) must be involved in the operation, each one controling what the other does
you run john that way (assuming a Unix or Linux system):

john password_file > /dev/null 2>&1
john --show password_file | sed -e 's/:.*//' > user_list.txt
rm ~/.john/john.pot

The user_list.txt file will contain only the name of the users for which the password was discovered by John The Ripper, but none of the persons running it has ever seen any password.


It is absolutely possible.
Traffic analysis attacks
Even if a VPN is honest about their claim that they do not log, their upstream ISP certainly logs. It would be unheard of for them not to. For a VPN (as opposed to Tor), the ingress and egress go through the same ISP, allowing trivial traffic analysis attacks. I explained a bit of this in this answer. Take the following series of events, with the ISP being the upstream ISP of the VPN (or a proxy):

ISP sees 203.0.113.42 send 253 bytes of data at t+0.
ISP sees the proxy server send a 253 byte request to example.com/foo.html at t+1.
ISP sees example.com send a 90146 byte reply at t+2.
ISP sees 203.0.113.42 receive a 90146 byte reply at t+3.

From this, it becomes trivial to realize that 203.9.113.42 connected to example.com/foo.html. This is a type of traffic analysis attack, specifically a traffic correlation attack. Virtually all ISPs keep this sort of information via NetFlow and similar ubiquitous systems.
Network stack issues
There is another problem with a VPN. You have to realize that the term Virtual Private Network is now more a marketing term. VPNs were never designed with anonymity in mind. The "private" in VPN refers to IANA-reserved private addresses specified in RFC 1918. It does not mean "right to privacy" or anything similar. All it is designed for is to connect two systems and expose them to each other as virtual network interfaces with local (private) IP addresses. This has several issues:

Your networking stack is "exposed", so a vulnerability in your kernel could be exploitable.
For this same reason, TCP/IP fingerprinting can  uniquely identify you, even behind a VPN.
You are forced onto the same NAT as a large number of untrusted users, allowing them to attack you indirectly, sometimes even allowing them to discover things like your hostname.

Visualizing the issue
It's useful to see how this all works, visually, in the form of a diagram. The single line represents traffic under your home IP, and the double line represents traffic with a different IP. A traffic correlation attack involves correlating the activity (timing and sizes) of both types of traffic.
How a plain connection works:
Client ----[Client ISP]----+
                           |
Server <---[Server ISP]----+

How a VPN works:
Client ----[Client ISP]---[       ]----> VPN
                          [VPN ISP]       |
Server <===[Server ISP]===[       ]=======+

How Tor works:
Client ----[Client ISP]---[         ]--> Node1
                          [Node1 ISP]      |
                   +======[         ]======+
                   |
                   +======[         ]==> Node2
                          [Node2 ISP]      |
                   +======[         ]======+
                   |
                   +======[         ]==> Node3
                          [Node3 ISP]      |
Server <===[Server ISP]===[         ]======+

You can see in this diagram how the VPN's ISP is in the position to trivially correlate the two connections, compared to a mixnet like Tor where every node's ISP must collaborate to have a chance at deanonymizing someone. This is not impossible, and an adversary who can see a significant portion of the internet at any given time may be able to pull this off a certain percentage of the time. It is very difficult to do, however, and the Tor protocol includes a number of features (both deployed and in active development) to make this even harder than it already is.
Another important thing to remember is that Tor will periodically switch the nodes it uses. Although the first node stays the same in order to avoid so-called Sybil attacks, the other two will change at most every 10 minutes, or whenever a different domain is visited. This reduces the chance that the final node sees too much traffic over time. VPNs, on the other hand, will naturally be static targets.
What this all means

Using a VPN (or proxy) does not protect you from the VPN's ISP revealing its logs, even if the VPN service is completely honest about their no-logging policy.
Your networking stack is exposed and visible to any 3rd party server you connect to, allowing potential exploitation and TCP/IP fingerprinting.
Anonymity networks like Tor provide some level of traffic correlation protection and hides your networking stack, though like all systems, it's not perfect.

If you need anonymity, you should use Tor without a VPN, unless a VPN is necessary to bypass a firewall that Tor cannot bypass, otherwise it would be superfluous.


The best way to store Passwords in Java applications , if you are running it on Windows bases systems is to use DPAPI from Microsoft, which uses the user's windows creds to encrypt the passwords. http://msdn.microsoft.com/en-us/library/ms995355.aspx.

There is also a Java wrapper for your convenience http://jdpapi.sourceforge.net/

Since Windows will manage your keys, you don't have to manage keys yourself. In Java, never think about writing your own mechanism to manage keys and store passwords. It is simply not secure because, any one having access to your .jar file can easily reverse engineer to the source code files and obtain your mechanism. CryptProtectData() is the way to go


When you run ps the output is the current running process list. Sometimes this will list the process including the command line arguments used to start the process. Here are some possibly dangerous looking commands from your output:

  453 0          996 S    /var/run/fakedns --port=63481 --address=/#/1.33.203.3
  502 0          832 S    telnetd -l /usr/sbin/login -u Alphanetworks:wrgn49_dl
 1127 0          988 S    udhcpc -i eth2.2 -H dlinkrouter -p /var/servd/WAN-1-u
 1853 0         1008 S    proxyd -m 1.33.203.39 -f /var/run/proxyd.conf -u /var
 1944 0          984 S    dnsmasq -C /var/servd/DNS.conf
 4379 0          968 S    /usr/sbin/phpcgi /htdocs/web/command.php
 4380 0          692 S    sh -c ps >> /var/cmd.result

I see fakedns is pointing all of your dns requests to
1.33.203.3.
Telnet accepting connections from only Alphanetworks.
It appears as if your traffic is being proxied to 1.33.203.39 (can't find any documentation on the -m flag).
You have a php page running under the name "command.php" I would suggest checking out the source code to that file.
The output of 'ps' is being appended to cmd.result (that may have been you).

In a possibly related note a google search for "proxyd -m" returns this gist.

If any/all of this seems phishy to you, I suggest factory resetting your device. If there are no available patches for your device see if you can load any open source firmwares (such as OpenWRT) and confirm the hash of the image when you download it.


What if I want a certificate, but DON'T want my domain in a Certificate Transparency log?

The best solution for a subdomain is a wildcard certificate:

To protect secretdomain.example.com, get a *.example.com certificate. But it's expensive. The wildcard could be submitted to ct logs, but it will not reveal the real domain name.

The two other solution are:

using a CA that don't sumbit certificates to ct logs, but anybody visiting your website could submit your certificate. (some bots crawl the web do to it)
using a CA that submit to ct logs with name redaction, but browsers do not yet understant it, it's at your own risk.

Another possibility is to transform secretdomain.com to notsecretdomain.com/secretdomain: with that you avoir ct logs, DNS logs, and even https leaks (when using https, the path is protected, but not the domain)


Is traffic sent by Mouse Without Borders encrypted?

From the support site, it says that communication is encrypted.

The comment is oblique and there is no overt indication in the documentation that things are encrypted. This is an example of the question being asked by others with no satisfactory answer.

From Wireshark, it LOOKS encrypted, but there is little from the developer on how.


How private is FB messenger video calling?

Like all other traffic going through facebook, it`s TLS encrypted, so sniffers would not be able to see the video.

I personally dont think that Facebook would store video calls because of limited resources, but always take these things with a pinch of precaution. If sharing sensitive data through video calls, try to look for an end-to-end encrypted service.

Storing metadata however, requries almost no space, so you can assume, they store at least a few things like who you called, for how long did you talk, timestamps, etc. It's just a few bytes of data, it takes nothing for them to store and information is power.


What are the benefits (if any) of changing TLS certificates frequently?

Renewing the certificate has no benefit, except if you use it as a substitute for revocation. Normally, a certificate is issued by the CA for some time (say, one or two years); to cope with abnormal conditions (e.g. the private key was stolen), the CA will regularly publish a list of "revoked certificates". A revoked certificate which looks good cryptographically (it is properly signed and all), but must nonetheless be rejected because the CA says it so. Revocation status check entails downloading the current CRL, verifying its signature and looking at its contents; this is bulky and cumbersome, and a lot of SSL clients (say, Web browsers) are tempted not to download CRL. If the certificates are very short-lived, then not checking revocation status can be tolerated: the CA, presumably, would not renew a certificate that it would consider as revoked.

This is an edge case. Usually, it is considered that the overhead of renewing certificates every week outweighs the cost of publishing and processing a new CRL every week.

Renewing the private key may have benefits. Remember that the certificate contains only the public key, so "renewing the certificate" does not necessarily imply changing the private and public keys; the CA could just take the existing certificate, change the validity dates, and resign it. But if the private key is changed, then so is the public key; changing the private key thus implies obtaining a new certificate.

Using a new private key may help in achieving a reduced form of Perfect Forward Secrecy. The issue that we want to deal with is the possibility of theft of the server's private key after the key was used. If the attacker records a TLS session, then, at a later point, steals the private key, then he may decrypt the session that he previously recorded.

Renewing the private key will grant you PFS insofar as the previous key is destroyed; it is not the obtaining the new key which grants PFS, but deleting the old one. Presumably, once deleted, the old key can no longer be stolen. This must be taken with a grain of salt, though: during the week the private key was active, it was stored on a physical medium (the hard disk), and really deleting data from physical mediums is tricky. It may also have been copied to some backup tapes or something similar.

SSL/TLS has a better way to obtain PFS. You get PFS by using one of the "DHE" cipher suites. With these cipher suites, the server's private key (the one corresponding to the server's certificate) is used only for signatures; the actual key for encryption (precisely, for key exchange) is a dynamically generated DH key pair, which the server never stores; the server keeps the private key in RAM only, for a few seconds. Since the key is never written to a file, it is much less susceptible to ulterior theft.

The symmetric key has nothing to do with PFS. In SSL/TLS, you always get a new symmetric key from each handshake: client and server send random values to each other, and these values enter in the computation of the symmetric encryption keys. PFS is not about using a new symmetric key; it is about not storing the asymmetric private key which would allow for reconstruction of the symmetric key (the DH private key for a DHE cipher suite, the RSA private key for a RSA cipher suite).

For a primer on how SSL works, read this answer.


How should a webmaster manage all her passwords and keys?

[Disclosure: I work for AgileBits, the makers of 1Password]

You already mentioned using a password manager for web logins. But for things like SSH and GPG/PGP private keys, you should consider a password manager which allows you to attach files to particular items and provides easy synchronization of this data.

Encrypted file systems.

Another option, not using a password manager, is to have an encrypted filesystem on some portable thing (USB thumb drive). The difficulty is finding a format that will work portably for you. If you only use OS X, then an encrypted DMG is an option, as you will be able to mount it and decrypt it on any Mac. I don't know what the Windows alternative is. Something like TrueCrypt might be an option, but you would need to also carry or install TrueCrypt wherever you go.

Things to avoid

I would avoid using something like a password protected zip file. First the password protection/cryptography isn't all that great, but more importantly it is too easy to end up leaving unencrypted data lying around.

I would also avoid trying to roll your own encrypted file system. There really are a lot of subtleties in designing such a system that most people aren't going to consider.

What I do

I, of course, use 1Password (see disclosure). Because it handles attachments, I can attach my various private keys to items in 1Password.

Drawbacks

The biggest problem I have with this is that 1Password doesn't run on Linux or FreeBSD. (There are some open source projects to build a 1Password reader for such systems, but they aren't ready yet.).

Also as much as I trust 1Password and my 1Password Master Password, I still feel uncomfortable storing both my PGP private key file and its password in the same well-protected basket. So I store my PGP private key in 1Password, but I rely on my memory for that particular passphrase.