Does Google Chrome protect against cross site scripting (XSS)?

Chrome has default protection against Reflective XSS attacks.  This is not a flaw that sandboxing can address.  This protection system works by looking outgoing requests for javascript and preventing that javascript from being executed in the http response.  No browser will prevent DOM Based XSS or Stored XSS.

Chrome's protection is the weakest when compared to the others. IE's xss filter isn't very good,  but slightly better than Chrome's.  From my research I think the NoScript is by far the best.  I have bypassed NoScript's XSS filter by exploiting content insensitivity,  and they fixed the issue quickly.  Chrome and IE still suffer from content insensitivity attacks.

Microsoft says that content insensitivity attacks against IE are "not a vulnerability" and they will never fix these issues.  Chrome has had a bug report open for this issue and I haven't seen activity for about 6 months.  So chrome might fix it eventually, maybe.  Which to be honest both of these are horrible vendor responses.  In general I find that NoScript and Mozilla have the strongest responses to vulnerabilities in their software and as a security researcher they are a joy to work with!


Should a password ever be presented in plain text to a user (On a website)? Is this illegal under UK Data protections act?

Theres no law regarding passwords. Only law that exists applies to personal details, but a password is not a personal detail. Since the password is often selected by the end user, under EU law this will Count as consent too, so even if someone would enter personal details as their password, it would Count as consent.

Depending on what the password protects, there might be security standards that laws will recongnize, for example Credit card details are protected under PCI DSS, Health information are protected under HIPAA, and so on. There also EU laws mandating how personal details should be protected. Those might mandate that passwords should not be stored in any recoverable form.

However, its a bad practice to display passwords like this. However, depending on what the password protects, it might not matter anyways.
One example is that all passwords are visible to a administrator, so a administrator can log in as any user. This might be a way to solve that some systems does not have "Takeover" capabilities where a admin can log in "as" any user.

Another way can be that the service being protected by the password, is also protected by any other means, like a firewall requiring a VPN dial-in Before allowing access to the protected service. And the password protection on this service are then not compatible with Single-sign on solutions or similiar, why the Company behind, simply show the password to login to This protected service, because even if the password do leak out, its useless to a attacker who do not possess the other means requiring to reach the protected service (like the VPN dial-in details, certificates and any OTP tokens).

If the passwords are to workstations in the Company in question, and those are physically protected (eg to reach the rooms where the workstations are located, a access card swipe is required anyways), then it wont matter if the passwords are shown anyways. You still need that access card to do any harm.

There also might be that this password does not protect anything valueable anyways, they just want a light protection on the web site to prevent general public access, but the information is still safe for the public to view, but if anyone hacks the website, no harm is done anyways.
Example: Product manuals available to customers of the Product. If those leaks out, it wont matter anyways.

Do a judgement if the information on the internal website is sensitive, eg "What happens if any unauthorized indivual accesses this website", and act accordinly. If the information is sensitive enough, you might want to report this to some security responsibile or something.


Can a file upload function be vulnerable without it the file name getting passed?

Most definitely!
File uploads can be very tricky and there is a lot that can go wrong.  There are (at least) two further steps you should take:
1. Verify that the file is actually a PNG
If you are expecting only PNGs, then you should verify that the file is actually a PNG.  To be clear, checking the extension is useless here - you want to check the actual file contents themselves.  If you don't do this you open yourself up to a few potential attacks of varying levels of severity:

An attacker can upload a JS file.  This can help as part of a multi-step attack by bypassing a CSP or other restrictions.
An attacker could host their own HTML files/images/an entire website on your website, potentially making phishing or other attacks much, much easier.
Depending on your server setup, an attacker may be able to upload scripts and have your server execute them, compromising your system.

2. Make sure the file cannot be executed by the server
Even if you check to verify that the file is a valid PNG, this may not be enough to stop an attacker from using your file upload to upload and execute scripts.  In particular, most image formats allow for comments and meta data in headers.  It is possible to put actual code in these comments, and in the event of permissively configured servers, the attacker may be able to trick the server into executing it.  Most modern servers with default configurations will be immune to such attacks, but attacks like this are possible and definitely have happened.
Bonus: Host somewhere else
The most straight-forward way of mitigating the above attacks is by hosting your uploaded files elsewhere.  Most modern cloud providers have buckets that are a perfect use case for this (AWS, GCP, Azure), but you can always manage it yourself with a separate server on a different domain that only serves static files.  By hosting the uploaded files on a different domain you skip the risk of CSP bypass, and by hosting it on a server that is incapable of treating files as code, you don't have to worry about missed vectors for RCE.  In essence, by immediately transferring uploaded files to a separate system, you're putting them in a sandbox for safety.


updatedb and encrypted home folders: Does it store unencrypted file and folder names somewhere?

The location of the database is  /var/lib/mlocate/mlocate.db or at /var/cache/locate/locatedb. This is outside your home folder. Probably you decrypted your homefolder prior to running the command and the results got saved in a non-encrypted folder.


Abusing write permission on Apache logs dir to escalete privileges

Directly from the docs, "see the security tips document for details"

  If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.


Changing browser to get your security fixed  is one pile of male bovine feces.

You say that you changed passwords, note that passwords should be changed at least every 90 days. A password history should be kept and passwords should be at least 8 characters, contain letters, signs, numbers and at least one upper and lower case letter. If someone leaves the company with access to shared accounts, change their passwords.

If the site has been up for 6 years you must review your patch management and see if you rolled at least all known security patches for the application, operating system, software running on the machine and programming languages used.

If the application is custom built it is recommended to get a pentest before starting the use of the app in production.

Make sure to review all logs especially the ones containing successful logins.


Best way to apply least privilege to one specific jar application on Linux

Create a wrapper program that has those capabilities, that just starts java on the correct jar file.


This is a genuine Microsoft Update site. If you go to any Microsoft KB article you'll see the link in the INTRODUCTION section (example). All old Windows Update addresses such as windowsupdate.microsoft.com and windowsupdate.com now redirect to the new update.microsoft.com.

The new domain seems to be a policy of unifying the update site for Microsoft's products under one name: Microsoft Update. As for the bad graphics and malware suspicions, a malware wouldn't really tell you to use a Microsoft application to update system. A malware usually tells you to click on shady links or asks you to download some "update helpers".


Is it impossible for an ISP to block access to a site that has a dynamic IP?

all the ISP had to do was to run a dns lookup on the domain itself to find the current IP and block that.

Definitely not impossible. In fact it is the way Russian ISPs are required by RKN to censor websites. The requirements are enforced by RKN-owned boxes inside ISPs networks, trying to get access to censored websites and reporting about it to RKN. It is supposed that an ISP is fined for each non-blocked website from the blacklist, though there are rumours that it is not always the case. Some people protest against censorship by buying expired domains still present in the statewide blacklist and making them point to government and big business websites, so ISPs must block them for their clients. There were some rumours about a whitelist of websites that should never be blocked sent to ISPs, though using this whitelist may be illegal for an ISP, so if an ISP wants to play safe, it must block the sites disrespect to the whitelist.

There more sophisticated methods of detection are also used.


Web-based intrusion detection integrating visibility into web app and database

i do not want to advertise a commercial solution, but there exists one database firewall i know of that offers such kind of db-protection you asked for, including learning-mode, whitelisting etc.

  Has anyone built it, and if so, how well does it work?

it works as well as your implementation. a good implementation is needed, since
each of these products needs to be finetuned. the better you define requirements, the easier it is.

automated whitelist-generation for both the WAF and DB-Firewall might be included into your regular deployment-cycles, e.g. generated on test-systems in learning-mode and updated/transferred on(to) your live-systems during deployments.

my pov: WAFs and WAF-style protection works very well against automated attacks and the dump, while not against those smart guys who know how to hide their attacks within regular requests proof: case1, case2

  Is there a standard name for this sort of system?

defense in depth :))))

  Are there existing systems like this available commercially or as open source?

no all-in-one solution afaik, and it wouldnt make much sense: you would like to have your WAF in your frontend-gateway and the db-protection between your appservers and databases. http-request are afar more complex than sql-queries, and the filter-approach is quite different. weaponized with lua you can blow up your waf to
a real cool toy, esp. when generating profile-based protection.

i usually suggest nginx+naxsi as a simple, pattern based waf, if possible pure whitelisting, and if you need more, a customized LuaWAF. on the db-level i go green :D

when you need more protection and want to filter not only incoming, but also outging traffic i'd suggest snort/suricata between your frontends/app-servers; i like this solution from a performance-pov; mod_security for instance, a solution we used before, is total PITA in both performance and rule-maintainance.


Does a compromised device always show an alien process running?

No.
Scenario 1:
A rootkit is running, which could hide any malicious processes which are running.
Scenario 2:
One of the 'usual' processes which you referred to could have been compromised, and you might not able to tell the difference.


There is an interesting paper which talks about securing IoT devices such as smart locks - http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-11.pdf

It has a section on relay attacks, which can be summarised more or less as:

Systems can under some circumstances use the GPS location of the mobile as a countermeasure for relay attacks, but:

this depends on the system knowing about GPS locations, etc and
apparently GPS location can be spoofed anyway

Otherwise they say there's nothing you can do to mitigate bluetooth LE relay attacks without requiring hardware changes or similar kinds of low level things.


How do I let users point to their own images, yet avoid Mixed Content warnings?

Would rewriting HTTP addresses as HTTPS work?

Only if the webserver hosting the images accepts https as well as http.

I would say the solution is to grab the images, and host a copy yourself, which you serve to your clients. Take the URL (or parse the CSS for images), download a copy, and substitute.


How does a zip file detect a correct password?

The Cyclic Redundancy Check (CRC) field is used to determine whether or not the file is decrypted correctly. Quoted from the original ZIP format specification:

  After the header is decrypted,  the last 1 or 2 bytes in Buffer SHOULD be the high-order word/byte of the CRC for the file being decrypted, stored in Intel low-byte/high-byte order.  Versions of PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is used on versions after 2.0.  This can be used to test if the password supplied is correct or not.

Update: As can be seen from Info-ZIP's unzip source code, the CRC value is used to check if the password is correct:

https://github.com/LuaDist/unzip/blob/master/crypt.c#L617

#ifdef ZIP10 /* check two bytes */
    c = hh[RAND_HEAD_LEN-2], b = hh[RAND_HEAD_LEN-1];
    Trace((stdout,
      "  (c | (b<<8)) = %04x  (crc >> 16) = %04x  lrec.time = %04x\n",
      (ush)(c | (b<<8)), (ush)(GLOBAL(lrec.crc32) >> 16),
      ((ush)GLOBAL(lrec.last_mod_dos_datetime) & 0xffff))));
    if ((ush)(c | (b<<8)) != (GLOBAL(pInfo->ExtLocHdr) ?
                           ((ush)GLOBAL(lrec.last_mod_dos_datetime) & 0xffff) :
                           (ush)(GLOBAL(lrec.crc32) >> 16)))
        return -1;  /* bad */
#else
    b = hh[RAND_HEAD_LEN-1];
    Trace((stdout, "  b = %02x  (crc >> 24) = %02x  (lrec.time >> 8) = %02x\n",
      b, (ush)(GLOBAL(lrec.crc32) >> 24),
      ((ush)GLOBAL(lrec.last_mod_dos_datetime) >> 8) & 0xff));
    if (b != (GLOBAL(pInfo->ExtLocHdr) ?
        ((ush)GLOBAL(lrec.last_mod_dos_datetime) >> 8) & 0xff :
        (ush)(GLOBAL(lrec.crc32) >> 24)))
        return -1;  /* bad */
#endif
    /* password OK:  decrypt current buffer contents before leaving */
    for (n = (long)GLOBAL(incnt) > GLOBAL(csize) ?
             (int)GLOBAL(csize) : GLOBAL(incnt),
         p = GLOBAL(inptr); n--; p++)
        zdecode(*p);
    return 0;       /* OK */


Is Google's password recovery by entering an old password a bad practice?

No. The correct/incorrect old password is just data used in a recovery process.
Google knows how you changed the password (via forgot password, via the normal change screen) and when, and how old the password is in numbers (eg you changed password 2 times after this old password).

So this data is used in a general scoring model to determite if you are a legitimate owner of the account.

So a example:

Entering the previous password, and that password was changed for a hour ago, google might allow you access with that old password immediately.

Entering a old password changed for a month ago, might direct you to the screen that allows recovery by secret question.

Entering a very old password, might get you to "get a SMS code to recover your account" procedure.

And entering a outright incorrect password might send you to the screen that require customer service interrogation Before recovering access.


The practice is always that all accounts must be approved by the system owner, not the admin. That means that any new account needs justification, definition, visibility, and is audited regularly to determine that the account is still valid.

Creating tons of user accounts and not disabling/deleting them is a massive problem. Each one can be exposed and because there is on one monitoring them, they can do anything.

Traceability is not a major concern, there will just be a lot of SIDs to track for the same user if you need to correlate activity.

My bigger concern is that this indicates a lot of other issues around administration that would likely need to be addressed.


I'm hesitant to post an answer simply because of the lack of data provided however simply based on the graphs, I would assume that this is due to someone using this server for DNS tunneling.  David Bianco has written up an article on DNS-tunneling detection by analyzing the network statistics.  He says that you can detect DNS-tunneling by seeing a very lopsided request/response of DNS queries which you seem to have.

A traffic-analysis approach to detecting DNS tunnels


Recover password of ZIP archive, having its decrypted and extracted content

Possibly, but maybe not in the way you think. AES encryption is resistant to known-plaintext attacks (i.e. where you can recover the key just by having both the unencrypted and encrypted data). This is assuming there are no other weaknesses or side channel attacks present in the implementation used for ZIP encryption.

Your only option is to try every possible password on the encrypted ZIP (which will take a long time), and you will know the key is correct when the decrypted result matches your existing decrypted copy. This is slightly better than not knowing what the unencrypted data looks like, but doesn't let you cheat AES. For more details, see these answers:

https://crypto.stackexchange.com/a/1515
https://stackoverflow.com/a/11716590


Is it a good idea to use an OpenPGP key that has no password?

Encryption does not require the private key

First of all, encryption does not require the password of the private key, encryption is peformed using the (unprotected) public key. The operation requiring the private key's passphrase is signing the data, do you really require this for your backup strategy?

Potential risks of unencrypted private keys

There is one obvious risk: if an attacker gets access to your unencrypted private key (ie. one without a password), he has immediate control over the key. If the key would have been encrypted (by a password), there would still have been the barrier of the password.

With other words: yes, this is a security risk; how large it is depends on your very specific use case, security practice and environment and can hardly be weighted by anybody but yourself.

To get a feeling whether this risk is something you want to take, consider (likely among others, this surely is no complete list):

chances of the machine/hard drive being stolen (in case it's not reasonably encrypted anyway)
somebody might get (physically) hold of the unlocked computer
you share the private key by accident or software issues
unpatched exploits in applications you use, allowing an attacker to backdoor your computer

Use gpg-agent

As an alternative, consider using the GnuPG agent gpg-agent, which is necessary with newer versions of GnuPG anyway, and allows you to cache your passphrase for a while (the exact duration can be configured), which reduces risks heavily without including too many hassles in daily use.


Meaning of ssl-cert section in nmap output

What you have there is information about an SSL certificate. The certificate identifies a computer, or more precisely a service running on a computer. The numbers after “MD5” and “SHA-1” are “fingerprints” of the certificate: the computer says that it can prove that it knows some secret value which is associated with these fingerprints. (MD5 has known attacks and SHA-1 is deprecated though; today SHA-256 or SHA-512 should be used for this purpose.) There is no way to obtain the secret values from those fingerprints — they're hashes of a public key, and the computer knows the corresponding private key. If you want to understand more about how this works, see How does SSL/TLS work?

The information you have here identify a service running on a computer (e.g. the RDP service). They do not identify a particular user of that computer. They have nothing to do whatsoever with any user's password or with any way in which a remote party could gain access to that computer. The information here is how another computer trying to talk to this computer can know that it's talking to the right computer.

Despite the appearance of sha1WithRSAEncryption, the information here is related to signatures (roughly speaking, how this computer can sign “yes, I am me”), not to encryption. The word “encryption” here relates to what happens during the TLS protocol, but not to the part where the certificate is directly relevant.


Capturing iTunes traffic with Wireshark - SSL decryption question

Cracking that tunnel is a non-trivial exercise. The short answer is that key store is located in the file /private/var/keybags/systembag.kb and retrieved with the kernel service called AppleEffaceableStorage under the locker tag \BAG1. This is the architecture:

The keys themselves are further encrypted and checksummed using AES and HMAC. It would be a big project for you to decrypt the stream. You would be much better off finding the memory buffer where the kernel process is storing the decrypted stream and just monitoring the buffer. I think the critical process is called keybagd (keybag daemon). There is also a kernel extension called AppleKeyStore which has a subcomponent called MobileKeyBag. One or all of those processes will own a buffer containing the clear text traffic.


Does adding a non-entropic part to a password makes it less secure?

No, longer is not stronger.

What makes a password strong is its entropy: how much unknown the password is to the attacker. Adding a "non-entropic" suffix to the password does not add to the entropy (by definition) so it does not increase the hardness of the task for the attacker. It does increase the hardness for the normal user, though, since that means more keys to type in.

Adding a known suffix or prefix does not lower security either, except in the indirect effect of encouraging the user to choose a less entropic password to make his job easier. Unless the password processing makes something dumb, of course. For instance, suppose that passwords are truncated to their first eight characters (typical of old DES-based Unix crypt()) and that you add a fixed 6-letter prefix to your password, turning "o7843vD!" into "123456o7": in that case, the prefix makes the attack much easier.


Is it safe to publish my development private key?

I think in case you will be using different SSL key, cert, and request in final solution. There no need to worry about publish them online.


What's the risk of changing permissions of the Security Eventlog registry key to IT operations?

DO NOT CHANGE PERMISSIONS ON THE SECURITY EVENT LOG.

If you change the permissions on it then any application running as the user with permissions can read it, and possibly write to it if you've given them said permissions. If I recall the registry key uses a SDDL format, and that is very easy to set up incorrectly.

You can't change entries with read or write permissions, unless you have access to the underlying event log file, but that's locked by the system.

Yes it can spoof security events.

It absolutely can lead to a DoS if the log is set up to cause a kernel panic once it's hit it's max size.

In any case, you shouldn't be modifying the registry key directly either. It should be done through WMI or through command line with wevtutil.

An installer (admin user) needs to create the log source before the application runs, or the application needs to dump its events into a predefined source. It's very easy to check if the source exists:

if (EventLog.SourceExists("YourSource")) { /* do your stuff */ }

You can also easily create the source by calling this:

EventLog.CreateEventSource("YourSource", "YourLogName");


Can TLS Compression be enabled on 3rd party CDN sites that have no authentication?

Compression-related vulnerabilities are about leakage: what the attacker can learn about the exchanged data, based on the data length. It makes sense only for confidential data; in the case of CRIME, the confidential data is the cookie which the client sends to the target server along his request.

If you have a server which does not exchange anything secret, in particular no cookie value, then there is no data to be leaked, hence no problem. Note that this is not restricted to cookies: if some secret requests are sent to the server (e.g. response to a login form with embedded password), then the attacker could try to use compression between that data and his forged request, since successive requests to the same server tend to reuse the same connection (TLS-level compression spans over the whole data flow, oblivious to HTTP request boundaries). We are talking about a server to which no secret data whatsoever is sent, and from which no secret data whatsoever is obtained. We must assume that not only the pictures are public data, but which picture is downloaded is also public information.

Note that enabling TLS-level compression will not buy you much anyway. Existing browsers do not support that compression any more, and pictures are already compressed.


Securing 2 factor data from apps that are co-located on the same device?

SMS or app:

App-style access is more secure on both major platforms since app data is sandboxed while SMS provider is publicly accessible from all apps. Android is a little bit more secure than iOS since it gives the user a list of privileges an app is using hence giving out a clue to the user to be more cautious when the app asks for SMS access (or, if using CyanogenMod, it can be even shielded from SMS by Privacy Manager).

On the other hand if the device is compromised sandbox won't help you much unless the sandbox is encrypted. I believe that iOS does this but I'm not sure, you'd have to ask some iGeek that. A sandbox breach clears the difference between sms or other app since sms app is just another app. Some OTP apps encrypt their secrets using a PIN and some devices have some kind of TPM circuitry that might be leveraged.

OTP secret compromise:

If your OTP secrets are leaked, the OTP can no longer be considered secure. You should negotiate new secrets ASAP. It equals to your hardware OTP token being stolen.


Why does tls_version "TLS 1.2" from howsmyssl rate "Probably Okay" in Chrome on Windows 10 but "Bad" in IE11 on Windows 7?

Well, from the error message you posted, your IE11 is willing to use some really out of date and broken crypto, but the Chrome does not. That tool even gives you a helpful description of why each one is considered insecure / vulnerable:

"insecure_cipher_suites": {
    "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA": ["uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"],
    "TLS_RSA_WITH_3DES_EDE_CBC_SHA": ["uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"],
    "TLS_RSA_WITH_RC4_128_MD5": ["uses RC4 which has insecure biases in its output"],
    "TLS_RSA_WITH_RC4_128_SHA": ["uses RC4 which has insecure biases in its output"]

Scanning that list of cipher suites with my human eyes, I would agree that the Chrome list is "probably ok" and the IE list is "bad", for exactly the same reasons as stated in the error message. Those are old and insecure, a browser should not be suggesting them to the server. If the server doesn't support any of the new good things, the browser should refuse to display the padlock.

Note that TLS 1.2 is just the version of the protocol (message types), and has almost nothing to do with the crypto. You want to be on TLS 1.2 because it gives you access to the good stuff that's not in 1.1, but 1.2 also supports old bad stuff for backwards compatibility reasons.


The preffered algorithm from that namespace seems to be PasswordDeriveBytes, though this is PBKDF1, which is nowhere as good as Bcrypt and probably should not be used.

PBKDF2 from a different namespace is probably preferable. Just note that the work factor there is linear, not exponential like in BCrypt and should be quite large.

I would consider using Argon2 from LibSodium with a C# wrapper. Libsodium is a reputable and well maintained library focused on ease of use.


Is HTTPS secure when using an online web browser?

In the worst case "online browser" is a bunch of figures and a label https:// in the URL bar means nothing.

There is no computational security scheme which addresses your use case. The security of connection between you and the site which you open in the so called "online browser" reduces to how much you trust the "online browser" operating site.

  Wouldn't my data be decrypted on their online browser

As I said there is no computational security in this use case. An "online browser" cannot be implemented in a way which secures the traffic between you and the website you want to access. An "online browser" cannot work without getting unencrypted data as no existing program can.

Summary:

"online browser" operator has all the data which would be secured with HTTPS otherwise
whether "online browser" uses HTTPS to communicate with target website or not is not computationally recognisable

  will the online web browser I use be able to see my traffic?

Yes.

  wouldn't the server see the online browser instead of my actual browser as the client?

It would. (the online browser may imitate your browser if it "wants")

  Wouldn't my data be decrypted on their online browser and re-encrypted and sent back to my actual browser via the online browsers HTTPS, thus allowing them access to my encrypted data?

Your data is not encrypted end-to-end, it only gets encrypted with "online website" before it reaches the target (if it ever is).


How does my unused e-mail address get spoofed?

NOTE: In the context of network security, a spoofing attack is a situation in which one person or program successfully masquerades as another by falsifying data, thereby gaining an illegitimate advantage.

How you can you get your emailed spoofed (the easy way):

The sender information shown in e-mails (the "From" field) can be spoofed easily. This technique is commonly used by spammers to hide the origin of their e-mails and leads to problems such as misdirected bounces (i.e. e-mail spam backscatter).
E-mail address spoofing is done in quite the same way as writing a forged return address using snail mail. As long as the letter fits the protocol, (i.e. stamp, postal code) the SMTP protocol will send the message. It can be done using a mail server with telnet.
Getting actively on website compromised by Beef framework or other  malicious JavaScript.(not your case I think)
Getting your email spoofed once will get it spoofed again.
Adding your email in a form or in a service that can be easly compromised or that can post or share your data as he wants.
Many companies in this world keep a browser at a lower version (to bypass HSTS) in order to fake certificate the connection. Yes the connection is still secure but they have the keys ... and how has the keys .. has the data.
Humans... maybe the like your email and they want to use it and use it and use it again.


Understanding PRGs: How can we expand randomness?

A cryptographically secure PRNG starts with an initial state (often called "seed") which is unknown to the attacker. We can consider the state to be a sequence of n bits. From that state, the PRNG works deterministically and outputs a lot of bits, the internal state being updated continuously.

There is a generic attack which can be theoretically applied to all PRNG, which is called "exhaustive search" or "brute force": namely, try all possible values for the seed, until a match is found with the observed output. The cost of this attack is, on average, 2n-1 "tries" (on average, you have to try half of the possible seed values before hitting the right one). This generic attack is thwarted by making n large enough that 2n-1 is a ludicrously large value. Good algorithms traditionally use n = 128 or more, which is large enough.

Of course, with a 2-bit initial state, exhaustive search is very fast: only 4 seed values are possible !

So we need a large initial state. The hard part is then designing a PRNG such that the generic attack is also the best attack; i.e. that there is no "shortcut" using the PRNG structure which allows for efficiently pruning out a large proportion of candidate seeds without trying them all. This is hard and is not well substantiated by mathematical theory: mathematically, there is no proof that a secure PRNG can even exist at all; so we put together a lot of "scrambling operations" which mix data together and we hope for the best. Even harder is to design such a mixture so that the result is not only secure, but also fast. Currently, the best we can do is to have some cryptographers put a lot of thinking in a design, and then submit it to many other cryptographers who try to break it for some years. Surviving designs are then deemed "probably secure". See the eSTREAM portfolio for such an effort.


Does it make sense to store RSA private keys instead of password hashes?

This is not secure. If you store the key you enable anyone with database access the ability to decrypt the user data.

You should not store the private key. Instead generate it on demand using the password + salt whenever needed. If entering the password every time encryption/decryption is required is not feasible for your use case then cache it in memory and clearing it when the user logs out.

RSA is slow and asymmetric. It also (as pointed out by A. Hersean) doesn't play well with key derivation algorithms. I would suggest you should probably be using a symmetric algorithm like AES for encrypting user data.


Yes. Some VPN will place all connected computers on the same net, without client isolation, thus you could jump from one computer of an employee to another (and from those to their home network, too!). Even if you can't do lateral movement between clients, it may be possible between different servers to which those users connect to.


Can I store secrets in localStorage? Will malware have access to it?

On PC's the browsers local storage and cookie storage is not specifically protected. This means that any process running with the same or higher privileges as the browser will be able to read and manipulate this storage. Thus, if you run the game as a different and low privilege user it will only be able to access the browser storage if it manages to elevate its privileges by using a security bug. But if you run the game as the same user as you run the browser no such exploit is needed.


You are thinking the whole solution wrong. The hosted buttons are meant for the cases when you have a few products.

My suggestion, use the passthrough variable "custom", where you on server create a MAC or other keyed hash over product, status, price, currency and user's IP.

This are then embedded in Custom.
On the receiver end, you validate the MAC before treating the payment as valid.

Even if they tamper with the price for example, the resulting MAC would not validate, and you know the payment has been tampered with. Thus you could either do a automatic refund, or you could validate the values harder, for example looking up the price in database and making sure everything match up.


What is the best method for key exchange?

This is exactly what SSL/TLS are supposed to do. SSL/TLS uses asymmetric encryption just in the handshake to exchange the symmetric key that is used from that moment on to encrypt the communication. The key exchanged is called a masterkey and is only used for that session. The lifetime of a session can be configured.

The process is basically this when you use HTTPS, for example:

Client establishes connection (three-way-handshake -> TCP handshake, after this the SSL/TLS handshake starts)
Server sends certificate (which includes the public key)
Client sends masterkey encrypted with the servers public key
Masterkey is used for that session

This is of course just a broad description of the protocol and only applies when the client itself has no certificate which is the case in most scenarios.


UEFI Secure Boot provides protection from this type of attack by requiring cryptographically signed executables.
Generally speaking, you need a tamper-resistant hardware module that validates the bootloader (e.g. a TPM chip).

To protect yourself from hardware backdoors you need something like the Intel Trusted Execution Technology. Basically, all your hardware modules (your HDD, your keyboard, etc.) have to have a way to identify themselves to the CPU. That means that all the chips on your motherboard and every peripheral devices you connect must include a tamper-resistant keystore (like a smart card or a TPM chip). And since the currently commercially available hardware does not include components like that you cannot do much.


What is the best way to organize OpenPGP keys?

One of the most secure and practical way to organize PGP keys is to use Subkey with offline Master Key.

In essence, with subkeys you can store your Master/(C)ertification key in an encrypted, trusted offline storage; and your day to day workstation only have the (S)igning and (E)ncryption key. You would only take out your (C) key when you need to sign or revoke your own or someone else's key, which usually happens much less often than regular signing and encrypting.

The reason why it's recommended to use separate (S) and (E) key is because many people uses multiple devices, and you can only have one (E) key in all your devices if you want to be able to read all your encrypted data from any one of your devices, but you can use multiple (S) key, one for each of your device, and all of your devices can still verify signatures because there is a trust chain to your master key.

Also, you can put shorter expirations on your subkeys. Master key is effectively non-expirable as you can always extend the expiry of a master key.

Note that newer version of GPG creates subkeys by default.


Answering my own question, so it doesn't remain unanswered and may help others.

I thought nuking from space (as suggested) might be overkill. I asked friends and got this advice, which I took:

Googling:
https://answers.microsoft.com/en-us/protect/forum/protect_other-protect_scanning-windows_10/virus-warning-big-red-page-wanting-me-to-call/b451426e-1408-40ff-b171-4c83a149b761

Did you visit Yahoo at some point in that browser session ... ? (No)

https://answers.microsoft.com/en-us/windows/forum/windows_10-security/google-chrome-critical-error/92ddd0e1-b860-4d63-b6af-f8a5da2c159f

Suggests accidentally clicking on an ad as a cause, and suggests
installing an adblocker (and clearing browser history) as a solution.

I also recommend running a complete virus scan before you do anything
else after you clean cache and cookies.

The problem has not recurred.


Is it possible to guess cvv code from payment number and expiration dates?

According to this article it is indeed somewhat possible.

Researchers at Newcastle University in the UK recently decided to see just how effectively the second caveat [that the payment processor mustn’t allow too many guesses at your CVV] was enforced, by trying to guess CVVs. [...]
If each website gives you five guesses, then with 200 simultaneous guesses on a range of different websites, you can get through 1000 guesses (200 × 5) in quick order without triggering a block on any of the sites.
And with 1000 guesses, you can cover all CCV possibilities from 000 to 999, stopping when you succeed.
Then you can go to a 201st site and order just about whatever you like, because you’ve “solved” the CVV without ever actually seeing the victim’s card.

The article goes on to mention that credit card fraud is far from uncommon and guessing the CVV isn't the easiest way of doing that, which I believe is likely to be true.
Worth noting is that some cards (like American Express) use a 4-digit code.


glibc getaddrinfo (CVE-2015-7547) vulnerability: should I update glibc if I do not configure DNS?

Should I update glibc if I disable DNS service?

  Should I update glibc if I enable DNS service?

The DNS service is about running your own DNS server. This bug is unrelated to this but is instead related to the DNS lookups done by the applications, i.e. your browser looking up the IP address of a site based on the hostname in the URL.
Thus yes, you need to update.

  Should I update glibc if I do not configure DNS? I have the following in /etc/resolv.conf

Unless the name server at 127.0.0.1 is a server which protects you this kind of attacks then you should update. Note that according to redhat the usual dnsmasq etc will probably not fully protect you:

  Can a trusted DNS resolver protect against this issue?
  A trusted resolver, in a default, protocol-compliant configuration, cannot mitigate this issue because potential exploits could involve syntactically well-formed DNS responses.


Possible to create a self-signed certificate with AIA extension using PowerShell or openssl?

First, to be clear, PS New-SelfsignedCertificate does three things: it creates a keypair in the Windows store, it creates a selfsigned cert for that keypair, and it stores the cert with the keypair in the store. Although creating the cert is the more complicated step of this process, by itself it would be useless; the cert can only be used in combination with the privatekey from the keypair.
You can do it with PS. As you found, -TextExtension doesn't seem to have a text format for AIA and needs the value to be encoded; in general ASN.1 encoding can be moderately complicated, but this case (AIA containing single OCSP) isn't too bad if the URL is not more than 113 characters (assuming I've counted correctly):
$s=[System.Text.Encoding]::Default.GetBytes("http://myca/onlinestatus")
[byte[]]$t=(43,6,1,5,5,7,48,1)
$t=(6,$t.length)+$t+(0x86,$s.length)+$s
$t=(48,$t.length)+$t
$t=(48,$t.length)+$t
$e=[Convert]::ToBase64String($t)

New-SelfSignedCertificate -dnsname example.org -certstore cert:\currentuser\my -TextExtension ("1.3.6.1.5.5.7.1.1="+$e)

If you want to use the same OCSP for all (or at least multiple) certs, you can do the first block once, save the encoding and re-use it where needed.
Or with OpenSSL, probably. You can (definitely) use OpenSSL to create a self-signed cert containing extension(s) 5 ways, all of them including the AIA extension and OCSP element, and all of them either creating a new keypair or using an existing one:

directly, with
openssl req [-config $cfile] {-newkey $parms -keyout $kfile [-nodes]|-new -key $kfile}  [-subj $dname] -x509 [-days $n] [-$hash].
This can use extensions from the configfile or in 1.1.1 only specified with -addext, as per the man page which links to the man page for x509v3_config for extensions (v3 was the version of X.509 that first defined extensions). Here you want authorityInfoAccess=OCSP;URL:http://myca/whatever.

create a CSR containing the desired extension(s) with openssl req {as above through -subj} and then create a cert for that CSR using openssl ca configured with copy_extensions=yes (which is not the default at least if using upstream) and other settings and/or options as needed.

create a CSR which does not need to (and for clarity should not) contain the desired extension(s) and then create a cert for that CSR using one of the following which adds the extension(s):

   3A. openssl req [-in $file else redir or pipe] -key $kfile [-config $cfile] [-extensions $sect|-addext ...] -x509 [-days $n] [-$hash]
   3B. openssl x509 -req [-in $file else redir or pipe] -signkey $kfile -extfile $xfile [-extensions $sect] -days $n [-$hash]
   3C. openssl ca not configured with copy_extensions=yes
(Yes that format is bad; I spent about 15 minutes trying to get markdown to do it without success. If anyone knows how to do it right please edit.)
All of these are subject to the OpenSSL limitation that it uses only keys (and also certs) in PEM files and does not read from or write to the Windows store. If you want to use this keypair/cert with a Windows-based app like IIS, IE or Edge, or almost anything in dot-net by default, it won't work. You need to either (1) create the keypair and cert in OpenSSL, pack into a PKCS12 (aka PFX) with openssl pkcs12 -export, and import the PKCS12 to Windows or (2) create the keypair (and possibly a dummy cert) in Windows, export the key from Windows to a PKCS12 and convert to OpenSSL's PEM format, use OpenSSL to create the cert, and import the cert back to Windows.
But I don't know why you want to. No relier will ever use the AIA (either OCSP or caIssuer) on a selfsigned certificate. A selfsigned certificate is expected to be a root, and thus it cannot be revoked by its parent -- it has none. A selfsigned cert can only be trusted by manually adding it to the truststore (either systemwide or specialized) and can only be distrusted by manually removing it (or disabling it if the truststore supports that).


WiFi security from another authorized user (roommate)

You can be monitored when you are on the same wifi network and the other person uses a wifi antenna that is in promiscuous mode. He can only see what traffic you are sending over the wifi network. If you are sending your journal over the internet without using HTTPS, he will be able to see them.

Your internet can be actively monitored, at least where you are going. There are countermeasures like using an encrypted VPN or SOCKS proxy.

Again for your passwords, if you are visiting the site in HTTP rather than in HTTPS, than anyone that has access to a point between you and the webserver will be able to see your credentials.

Solutions:

get your own wifi
invest in an encrypted vpn
invest in a SOCKS proxy server
Use HTTPS

P.S. This is the same for Mac and PC.


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

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

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

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

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

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

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


These devices are called IMSI Catchers, and are in use by state agencies and law enforcement entities. I doubt whether you can get such a device for private surveillance.

I also doubt whether you will succeed preventing theft with such a device. A sopisticated thief will not carry HIS mobile around.


Directory transversal in PHP with the $_FILES array?

According to my experience, $_FILES["uerrfile"]["name"] already consists of only a filename part, with the path stripped out.

However, the PHP manual suggests to use the basename() function anyway, so I am it no position to tell you otherwise.

On a side note, I wouldn't advise to use the original filenames anyway as they are highly inconvenient to handle, given they could be duplicated, or contain special characters, or be too long and get truncated, etc.

So a new name assigned by a system would be more usable. Personally I developed a habit of naming the files after md5() from the file contents, or you can use any other method such as uniqid().


How do I store a swipe pattern in a password manager?

I would suggest giving each phone a name, then for the password use the keys on the num pad to represent the dots to hit.

For example, if you have a swipe pattern in the shape of an L (starting on top left), your password would be 74123.  If you go with every dot in a "Z" shape (starting on top left), the password would be 789654123.

Most can't store pictures, but that would be another option.  Take a picture of dots or draw them out on Paint, then draw the lines showing the dots to hit.  Then you can just name the file something to do with the phone it's for, then store it somewhere only you have access to.

Example of "Z" Shape as a picture


Protecting local admin password against 3rd party software

Yes, it is possible. There is known Windows malware that can grab the Admin password hash from memory, even if you never log in to the Admin account after infection.


Is Postgres password-based authentication secure?

If using SSL, then what PostgreSQL does is fine. If not using SSL, but still doing the authentication across the network, then what PostgreSQL does stinks. Their games with MD5 are worthless, but not because they use MD5. MD5 has its own issues, but there they are just misusing it awfully.

With "cleartext password" authentication, the client shows a user name and a password, and the server accepts them if they match what the server stored.

With "md5" authentication, the client shows a value (which happens to be the MD5 hash of the concatenation of the password and the user name) and the server accepts it if it matches what the server stored.

So you see it: in both cases, the client shows a bunch of bytes to the server, always the same sequence. It suffices for an attacker to tap on the network to observe these bytes, and then connect to the server and sends the same bytes to be granted entry. That the bytes are the result of a MD5 hash is completely irrelevant here. This MD5 hash is said to be password equivalent. As long as the connection can be eavesdropped at all (i.e. no SSL), then security goes down the drain.

See this page for the details of the MD5 computation. They call it "encryption", which it is not at all (hashing is not encryption).

We could even argue that using this MD5 decreases security: when a plaintext password is used, it can be forwarded to another authentication server (using Kerberos, LDAP,...) and that authentication server could then employ strong storage techniques (see password hashing). With the PostgreSQL-specific MD5 hash, this cannot apply. When the "md5" authentication method is used, it MUST be against a table in the database which contains all these "md5" value as is. An attacker who can get his hands on, say, a backup tape or an old disk, will immediately obtain many free accounts on the database.

And, I insist, nothing in all this has anything to do with MD5 cryptographic weaknesses. All of this would still apply if MD5 was replaced with SHA-512.


wipe encrypted disk by nulling the first few bytes?

Some FDE schemes, such as BitLocker, store their metadata (plain-text information about how to decrypt the volume, plus things like the encrypted master key and how it is protected) in multiple places, scattered across the volume. This is done for redundancy against minor disk corruption causing 100% data loss. You would need to wipe all of the metadata to prevent somebody who would otherwise be able to decrypt the master key from decrypting the volume.

Even aside from that, though, wiping the first few bytes won't do anything at all unless you did something like use openssl to encrypt the whole volume directly, instead of using an actual full-volume encryption tool. The reason is that the first few (hundreds of) bytes of the volume is metadata about stuff like what file system is on the volume (or what full-volume encryption scheme was used and where to find its metadata). The first few bytes of this is almost always either irrelevant, predictable, or both. Wiping it won't save you anything.

Finally, even if you did something like the "openssl the whole block device" idea, nulling "the first few bytes" doesn't add nearly enough entropy to prevent somebody from just brute-forcing the encryption, assuming they know the key. Let's say you wiped three bytes. Three bytes is 24 bits, or roughly 16 million possible values. Assuming the attacker has a way to test any given possible value for those three bytes (to see if it's what they were before being wiped) in less than 1000 AES decryption operations (realistically it'd probably be much less). Given modern hardware-accelerated AES speeds, your typical desktop CPU could find the original value of those 3 wiped bytes in under a minute.


Is it possible to get infected by malware from running a foreign Xcode project?

If you run un-trusted code on your box ... it is no longer your box

That being said, if you do a full backup of your Mac and Airgap it before running the code.  Then wipe it, and reinstall from backup before connecting it to anything ... you should be ok (as long as a rootkit isnt injected into the firmware which is low probability but still a risk).

Short of that, I would read through every line of code and verify the integrity of any/all third party libs the code is using before running it ... and even then I would step through the entire thing.

IMO if this entrepreneur is willing to buy you a new computer to test the code on ... I would say go for it.  However, judging by his decision to hire this other group to write the beta code (aka cheapest outsource work he could find) ... I doubt he is paying you enough to take the risk with your own computer.


Authorization/authentication strategy for micro service apps

This sounds different from what I've heard about previously. My understanding of a typical microservice architecture is that you'd have a variety of fine-grained microservices, composited together into one or more coarse-grained applications.

In that view, you would probably have a single E-Commerce Web App, which utilizes a variety of microservices in the backend (the cart service, suggestion service, search service, etc.).

If that's the case, then there's only one "App" that the user interacts with: the Web App. The user would sign into the Web App, and then the user's ID would be delivered to the various back-end microservices.

If the Web App talks to the backend services using a private interface, then you can just pass the user ID directly - it's not really any different from passing, e.g., a user ID into a database query. If you've got a public interface that you're using, then you might need to pass something like a session key around - although, that would depend on exactly what sort of public interface you have.

Note: all of this assumes that you're talking about a server-side microservice architecture, since you cite list "rails" as a related technology, but not anything specifically client-side. Using web APIs over Ajax is something that I'd consider to be a separate topic.


Do you have to reset CSRF token after login?

if a session and a token is generated before login to protect against
  login CSRF, should you reset the token if the user successfully login?

OWASP recommends that session tokens be renewed on a successful login to prevent session fixation attacks,with CSRF attack the thumb rule is a token which cannot be guessed by an attacker beforehand and forge a request with it.Your application logic seems to follow that rule.Unless you messed up somewhere else this should work.


Is it enough to only wipe a flash drive once?

Best stop doing that. Never overwrite an SSD/flash storage device completely in order to erase it, except as a last resort.
NVRAM has a limited amount of write cycles available. At some point, after enough writes to an NVRAM cell, it will completely stop working. For modern versions, we're in the ballpark of an estimated lifespan of 3,000 write cycles.
Furthermore, internally SSDs look nothing like traditional hard disks. SSDs have the following unique properties:

Spare area, often on the order of 8% - 20% of the total flash is set aside for wear leveling purposes. The end user cannot write to this spare area with usual tools, it is reserved for the SSD's controller. But the spare area can hold (smaller) amounts of old user data.

A "Flash Translation Layer", FTL. How your operating system 'sees' the SSD (LBA addresses) and the actual NVRAM address space layout has no correlation at all.

Very heavy writing to a consumer-grade SSD may bring the controller's garbage collection algorithm behind, and put the controller into a state of reduced performance. What happens then depends on the controller. In an extreme worst case scenario, it cannot recover performance. In a much more likely scenario it will slowly regain performance as the operating system sends "trim" commands.

Lastly, from the conclusion of the paper "Reliably Erasing Data From Flash-Based Solid State Drives": "For sanitizing entire disks, [...] software techniques work most, but not all, of the time."
So when you're completely overwriting flash storage, you may be performing an effective secure wipe -- but, you may also be missing some bits. And you're certainly consuming quite much of the drive's expected life span. This isn't a good solution.
So, what should we be doing?

The 'best' modern drives support a vendor-specific secure erase functionality. Examples of this are Intel's new 320 series, and some SandForce 22xx based drives, and many SSDs which are advertised as having "Full Disk Encryption" or "Self Encrypting Drive". The method is generally something along the lines of:

The SSD controller contains a full hardware crypto engine, for example using AES 128.
Upon first initialization, the controller generates a random AES key, and stores this in a private location in NVRAM.
All data ever written to the drive is encrypted with the above AES key.
If/when an end user performs a secure wipe, the drive discards the AES key, generates a new one, and overwrites the old AES key position in the NVRAM. Assuming the old AES key cannot be recovered this effectively renders the old data unrecoverable.

Some drives don't have the above, but do support the ATA Secure Erase commands. This is were it gets more tricky -- essentially we're relying on the drive manufacturer to implement a 'strong' secure erase. But it's a black box, we don't know what they're actually doing. If you need high security, then you should not rely on this, or at least you should read the tech docs and/or contact the drive manufacturer to verify how secure their method is. A fair guess as to what they're doing / ought to be doing is that:

While the drive isn't using a full cryptographic cipher such as AES, it is still using extensive data compression algorithms & checksumming & RAID-like striping of data across multiple banks of NVRAM. (All modern high-performance SSDs use variants of these techniques.) This obfuscates the user data on the drive.
Upon receiving an ATA Secure Erase command, the drive erases its "Flash Translation Layer" table, and other internal data structures, and marks all NVRAM as freed.

My personal recommendations:

If you just need an insecure wipe of an SSD, then use the manufacturer's end user tools, or use the ATA Secure Erase command via for example hdparm on Linux.

If you need secure wipe then either:

Only use drives which explicitly advertise secure wipe via strong (AES) encryption, and run the manufacturers secure wipe. and/or:
Ensure that all data you write to the drive is encrypted before hitting the drive. Typically via software full disk encryption such as PGP Whole Disk Encryption, TrueCrypt, Microsoft BitLocker, BitLocker To Go, OSX 10.7 FileVault or LUKS. or:
Physically destroy the drive.


Is it too late to encrypt my already used USB drive?

Is it too late to encrypt my drive even if files are on there already?

You can "turn on" Bitlocker To-Go to encrypt the files/folders already on the USB drive.

However, as the other post indicates, this may not remove all traces of the unencrypted data due to hardware specifics of memory controller/flash/etc, but it is better than nothing as an immediate course of action.


Why am I getting strange HTTP requests for non-existing pages?

These types of spurious requests are very, very common. They are either looking to see if you are already compromised, or looking to get your server to throw an error to gather info about your server (from error messages).

You aren't the only one:

http://shadow.wolvesincalifornia.org/awstats/data/awstats092014.shadow.wolvesincalifornia.org.txt

# URL with 404 errors - Hits - Last URL referer
BEGIN_SIDER_404 193
/admin.php 1 -
/root/back.css 1 -
/drdr/drd/dr.php 2 -
/hkhk/hkh/hk.php 1 -
/wp/2011/07/19/&amp 6 -
/ahah/aha/ah.php 1 -
/andro/back.css 1 -
/wp/comments/feed/ 1 -
/wjwj/wjw/wj.php 1 -

We all get spammed by these requests.


How secure is Keepass when using mobile apps

The problem with any application that can access your password safe contents is that it could potentially do anything with the passwords: send them to a server, save them on your hard drive in plain text format, delete them, change one character in every entry, etc.

This applies to both open source and closed source software, unless you are examining the specific actions which are taken by the executing program. Can you be sure that the copy of KeePass you have was built from the same code as you can download?

You have made the decision that the official version of KeePass is trustworthy, and won't steal your passwords. You now have to decide whether you trust the unofficial mobile ports to the same degree, which depends on your appetite for risk.

Things to consider:

Potentially fewer users than the main Windows version, so reduced chance of issues being picked up
Difficulty of checking exactly what code is running on a mobile device (even if the code is available)
Potentially increased risk of unnoticed outbound connections

However, even given this, assuming that whatever mobile application you pick is not malicious, you keep a greater degree of control over where the main password safe file is kept than with a cloud password manager. You can always keep a full safe on your computer, and a secondary one on your mobile device, containing a subset of passwords. In that case, even if the app turns out to be malicious, you would have a core of unaffected high risk passwords, although it loses some of the convenience of a password manager.


Sending multiple MAC addresses to the same port on a switch

That depends on the firmware of the equipment.  Since you asked, "What COULD happen," I'll enumerate (from the POV of an embedded software engineer) what I can think of.

The switch may pass all frames on regardless of the source MAC.
The switch may reject frames arriving at a single port when the source MAC  differs from the source MAC recorded when the wire protocol began if a breach of that protocol has not been detected.
The switch may record the discrepancies in a log that network engineers can read after authenticating with the device.
A bug could be triggered, rendering the device unstable or inoperative until rebooted.

The first of these may be a security risk depending on the nature and security in place on the other equipment receiving such passed frames.


Can a malicious optical disc infect Ubuntu without user action?

My best guess would be that the disc is carefully crafted (using typical optical disc burning methods) to exploit security holes in the optical drive firmware or the auto-running software of Ubuntu. So yes, having unlimited resources one can achieve what you are describing.


OAuth 2.0, what should it be returned in the authorize endpoint if the client_id is wrong and no redirect_uri is passed

Everything is well explained in the request for change you pointed:

The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise) and includes the following
parameters with the response:
invalid_request
           The request is missing a required parameter, includes an
           unsupported parameter value (other than grant type),
           repeats a parameter, includes multiple credentials,
           utilizes more than one mechanism for authenticating the
           client, or is otherwise malformed.

And this is typically the case you described, if the request is missing the client_id or the redirect_uri you should return an HTTP/400 Bad Request as described in section-5.2 of the RFC:
  HTTP/1.1 400 Bad Request
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "error":"invalid_request"
     }


I am a little surprised by the behavior you're seeing, but do have a suggested workaround.  In particular, the registry key HKCU\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\deployment.webjava.enabled is responsible for controlling your configuration setting.  GPO can trivially set this value and the permissions on it to ensure that your end users have rights to enable the feature.  See this technet post on custom registry changes through GPO.

By going this route, you ensure that the feature is disabled during the application of GPO while logging on.


Is radio burst transmission really "jam resistant"?

Yes. This is why it was not described as "jam-proof". However, it just so happens that transmitting powerful RF waves across the entire RF spectrum is a) very, very power intensive (like "you can't do this outside of a fixed installation near a dedicated power plant"-type power intensive), b) ruins your own systems as well, and c) makes you an excellent target for anti-radiation missiles. The whole point of jam-resistant stuff is to make it so that the enemy, who has finite amounts of power, doesn't know when and where to transmit to jam the signal. It's simply not practical to transmit high power across a broad spectrum for long periods of time.


Encrypt a textfile with gnupg on the console

Encrypting is as easy as decrypting:

gpg --encrypt /tmp/message

GnuPG will now ask you for the key(s) to encrypt to. The encrypted message will be stored to the same path with .gpg extension. The output file can be set using --output /path/to/encrypted/file.

You can also include the recipient as parameter, useful for scripting gpg, add --recipient foo@example.org.

For more options, read man gpg and the GnuPG manual.


Ethical approach about corporate website and vulnerabilities

The ethical approach is to report, confidentially, and to not combine the reporting with a request for payment to fix it, which could be seen as extortion.

Explain how you found the problem, and possibly include steps to remedy what you found, but leave the fixing to them.

As a Security Manager for an insurance company, I can tell you that I would be grateful to know about the problem, but would shut the door in your face if you started to try and turn it to your advantage. If, instead, you worked with me openly to fix things, helped to retest, and generally was pleasant to work with, I might offer you a job at the end, or at the very least, offer a letter of reference for your skills and professionalism.

In the end, it is THEIR website, and their responsibility to fix, or not to fix.


Bot detecting by considering request inter-arrival time

Here at Incapsula we actually use some of these methods for bot detection (i.e. JS and Cookie challenges) but I`m not sure about the page-view-time metric.

For one thing, you want to detect and block malicious bots as quickly as possible and there are better things you can do then to wait around, even if it's just for a short while.

I also have to agree (+1) with @yfeldblum about the Expire headers and their ability to interrupt resource-load based tests. Having said that, CND and Multiple servers are not an issue if the challenges are performed by the CDN provider himself.

I also wanted to contribute few other ideas for bot detection:

Behavior (i.e. early access to robots.txt)
HTTP Header order/missing parameters

Also, I would like to suggest not to rely exclusivity on any of these methods because this will lead to false positive identification. Instead, try to combine them into a step-by-step cross verification process.
(i.e. JS challenge -if failed-> Cookie challenge -if failed->Robots.txt access and so on....)

Finally, at some point you'll have to start collecting and relying on signatures to minimize redundancy.

After all, you can't keep testing Baidu bot every time it visits, this is just one step away from a self-inflicted DDoS. :)


Could the FBI dump the drive contents of an iOS device, and then somehow run Virtual CPU's with different keys?

If the filesystem is encrypted, then no, they couldn't, as far as I understand the arrangement on newer iPhones (models with fingerprint readers).

Or rather, they could copy the contents of the phone's storage and mount it on a computer of their choosing, but they wouldn't be able to read it because it is encrypted with a 256-bit AES key which is (presumed to be) beyond their ability to brute-force.

The original phone holds a copy of that key, of course, but it is stored in the "Trusted Enclave", a separate system-on-a-chip which keeps the key in its internal EEPROM and won't reveal it until it sees a correct user passcode.  The Trusted Enclave itself implements a timeout after repeated wrong entries, so even transplanting it into a custom-made circuit wouldn't help you to brute-force the (weak, four-digit) passcode.

Whether the Trusted Enclave chip could be breached physically, I don't know, and I doubt that could be answered without public-domain information.  It would be a formidable task, though, even if the chip's casing isn't tamper-proofed in any way.  The components you'd need to connect to are made from a small number of molecules, and even if you had the time and money and equipment to do it there'd be a strong risk of damaging the chip and losing any possibility of recovering the data.

If this is related to the San Bernardino case currently in the news, the situation is a little different because that relates to an iPhone 5C, which does not have the Trusted Enclave.  Presumably you could open the phone and read the whole system image from the flash memory into a virtual machine (which ignores any code-signing protection), and then hack the OS to allow the passcode to be brute-forced.  That's still a pretty big job, but it's not unthinkable that the FBI could do it in exceptional cases.  It would be much easier for Apple, but there is also a political dimension to (a) the FBI requesting that and (b) Apple resisting.


Is a "magic link" a kind of authentication?

Do you know those "Login with Facebook" and "Login with Gmail" buttons all around the web? They are almost the same.
When you allow someone to login with their Facebook account, you are validating that the person have access to that Facebook account and in no way confirming his identity. That confirmation is being delegated to Facebook.
A magic link does essentially the same. Opening the link does confirm that the user have access to the email, but the authentication is being delegated to his email provider.

Anyone who knows my email can request sign-in link on my behalf

People that know your email can try to login on your behalf, and they can do exact the same on your email provider. And on any service on the internet. Being able to try to login isn't the same as authenticating themselves, so it makes no difference.
They won't be able to login because they don't have the link, and if you click on the link, you are logging in, not them. So it does not matter.

Can this be used with public emails like Gmail, Yahoo?

They are not public emails. I have a Gmail account and I am pretty sure it isn't public. A public email would be those disposable emails (like Mailinator, for example).
A public email from Mailinator can be read by anyone, so if your service says "The link has been sent to supersecret@mailinator.com", anyone can just get there and grab the token.
But if the token is sent to "supersecret@gmail.com," only the owner of that email can access the token. And it makes no difference if the email is from Google, Yahoo, or the White House: only the one (or ones) with access to that email can have the token.

If this is considered a form of authentication, can it be compared to the auth_code authorization grant in oauth?

If the token cannot be reused, it's the same as OAuth.


1) Is the outbound email secured when sending it like that?

No. The setup you use is just a minimal setup and does not enforce TLS with proper certificate validation to the target mail server.

  2) What can I do to further secure the outbound emails? Encryption? Tls?

The best is actually to encrypt the mails itself and don't rely on the security of the transport, because mail transport does not offer much security. For proper end to end encryption of mails use PGP and S/MIME.

  I do have a certificate from Let's Encrypt, but not sure if it will matter here?

It does not really matter. Since you are only sending this certificate could at most be used as a client certificate to authenticate against the target mail server. In your current setup this does help. If you would use a fixed target mail server and would set this up to require and properly verify a client certificate then it might help.

But again, the easiest way to get better security is to use PGP or S/MIME to encrypt the message itself and not rely on the security of the transport.


Password security and entropy - degeneracy question

There are many ways to calculate entropy in this situation and not all of them are in your favor.  Depending upon your commitment to true entropic randomness and your level of paranoia, I think word concatenation is the least of your problems.  For purposes of analysis, I'm going to assume the password example you gave above is standard for all types of passwords you create (8 complex password characters + N words containing 18 total characters -- or 26 total characters).

Method 1

Assume every character in your resulting password contributes entropy to the result. Furthermore, every character may be within the range [33..126] or 94 possibilities. In this analysis, total range of passwords is 94^26 or 2*10^51. That sounds really big, and it is. However, I'm not sure that's your password range. We could stop here if we believed that an attacker could only guess from the complete range. You already know dictionary attacks are possible. Let's look at the next method.

Method 2

Really, only the first 8 characters are in the complete range, the remainder (if I can guess your word component) is only lowercase, so 26 characters. This gives us a lower upper limit on your range of passwords: 94^8 * 26^18 = 1.8*10^41. That's still pretty big, but we're not done, yet.

Method 3

Let's look more closely at your password structure.  The first section is the only one that can have the full 94 characters, so for that we have 94^8 or about 10^16. For the second section, should we count the letters as part of the range of your passwords? I suggest they don't count, and instead we should use the total word range from which you choose and the number of words. Why? Think of the words as unique symbols rather than the characters. Your second section will never have the sequence "xxyqrzt" because there's no word that looks like that. Really, your second section follows a specific structure and that structure is determined by your dictionary. I'm going to assume 100,000 words in the dictionary, although you might only have 10,000 and that they are all lowercase. Now, the second section range is (10^5)^3 - I'm assuming three words to get to 18 characters. Our new upper bound for the password range has dropped to 10^31. Still, pretty big. We're done, yet.

Method 4

OK, so this one requires us to go a bit deeper on entropy calculations across the range of passwords and then do the proper entropy calculation for your situation.

First off, password range and entropy are not the same thing, although they are related. To get the entropy of a password (or any information), we need to take the log of it's possible range. We should use base 2 for our log because it's easier and computers use it, too.  In this case, we have the following entropy calculations for each of the above methods of analysis.

Log_2(2.0*10^51) = 2^170 or 170 bits
Log_2(1.8*10^41) = 2^137 or 137 bits
Log_2(1.0*10^31) = 2^103 or 103 bits

It's easier to think of entropy in terms of bits.

Here's the thing. You've now published your password generation algorithm. Also, security through obscurity is not really security, so theoretically or practically, someone could discover your algorithm. In that case, the only real security for your system, the only real entropy introduced is the seed for your random number generator. If you're not using a secure RNG or a securely seeded PRNG, you've already skewed your password distribution.

What this means is that to get the full effect of your password entropy, you need to introduce at least 103 bits of true random seeding to your random number generator to select from the complete range of passwords available from Method 3.

I suspect you aren't doing this (or, at least haven't, up until you read this). So, if the RNG you use seeds itself with current time or process ID or MAC address or IP address, you might have a lot less entropy than you realize.  The entire MAC address, IP address and time don't count because most of the bits therein aren't really random, they can in fact be known. Think about it. The difference between now and a few seconds from now is only a few bits of data.  If I can guess when you generated the password, it might be NO bits of data. You might only have a handful of bits, perhaps no more than one dozen.

That would be a range of passwords of about 2^12 or 4000.  More passwords than you'll ever need, however, you'd never know the range was so small because the passwords look so big.  You can't generate more entropy from less entropy in this situation.  If you don't believe me, test it yourself by running numbers from the range [1...4000] through SHA1.  The results look really random.  However, that's it for your hashes - 4000 only.  None of the other potential SHA1 hashes are available to you because you're limited to inputs between 1 and 4000 inclusive. In this case, the entropy of the range is still 12 bits even though it looks really large. Looks can be deceiving, especially to humans.

So, forget all of your fancy analysis and multi-word fears. Instead, figure out how to get true randomness into your RNG seed.  Go look up the body of research on proper RNG seeding. It's fascinating and it's really, really hard to do!


What is the best way for high-level anonymity and privacy via Tor?

Mixing Tor and VPN is potentially very risky!

If you establish a VPN connection, then a Tor circuit, the Tor entry node sees the VPN exit IP, and your ISP sees only the VPN activity and this potentially works fine if everything is correct. Unfortunately it’s not uncommon for VPNs to leak information (such as DNS), in which case a VPN flaw potentially negates the anonymity of Tor before it even gets used. Ask yourself what advantage you are deriving here? Hiding the fact you’re using Tor from your ISP may be worth it in some instances or countries.

If you do the reverse and establish a Tor circuit, then a VPN connection, you’ve completely defeated the anonymity of Tor as you are logging into the VPN with a registered and paid identification. If you paid for the VPN using some form of anonymous payment and gotten your account information via some other form of anonymous communication, and you never make the mistake of directly connecting to the VPN, this approach can work. Except for rather unusual circumstances, this is a whole lot of risky moving parts that are more likely to harm than help.

Multiple security measures do not necessarily increase security, quite the opposite sometimes. Ask yourself what you’re trying to accomplish before throwing tools at the problem.


How can I prevent someone from accessing a Windows XP system via boot disk?

The real issue here is that the attacker only needs physical access to your hard drive in order to read or manipulate the files which contain your password hashes.  There is already a thread on SuperUser which has some recommendations, which I will likely repeat here.

How to secure my Windows 7 PC?

As security compromises of a PC go, physical access is perhaps by far the worst kind.  Once an attacker has their hands on your computer, most other security methods in place are easily circumvented.  That said, here's what you can do to prevent or hinder these attacks from affecting your system.

Use strong passwords.  Make them 15 characters long at minimum, and use all four character types (lowercase letters, uppercase letters, numbers, non-alphanumerics).  Also, avoid using any dictionary words in any part of the password.  Lastly, do not write it down!
Encrypt the hard drive.  This will prevent any attacker from reading or manipulating the system files when booting into their own environment.  This is the only measure that will generally survive an attack involving physical access to the system.  Also, see item 1.
Lock down the BIOS and Boot Order.  Set the system to only boot to the system drive, and set an Administrator password on the BIOS so that this cannot be changed.  Also, see item 1.
Physically secure the system case.  If possible, lock the system's chassis with a padlock and/or place it in a secured cabinet.  A chassis lock will hinder efforts to clear the BIOS password by using jumpers on the motherboard, and efforts to remove the hard drive for loading into another system.  A secured cabinet will do that, and also hinder any attempts at plugging in or loading alternative boot media.  For ideal security, and if you're really paranoid, do both.


Incrementing Work-Factor of Hash Functions Over Time

You seem to have summed it up pretty well.
The only drawback I can think of is inactive users in your system - they will continue to have a previous work factor because they may never log in again, or may not have chance to log in before your next breach, meaning their stored password is more vulnerable to attack. As work factor is visible within the stored data, the attacker would know which ones are using the old setting (although they will not know the relative entropy within each password).
To prevent this, you could regularly disable accounts that have not been logged into for say 6 months, blanking their password at the same time. If they need to login at a future time, they can simply go through your forgotten password functionality to enable a new password to be set and stored with the new work factor.


You can use scapy for this. One approach is to record one or more ARP packets first:

pk = sniff(count=1, filter="arp")
pk.summary()

And later use this to build your own ARP request:

arppk = eval(pk[0].command())

Now you can set own values in arppk:

arppk[ARP].hwsrc = 'AA:AA:AA:AA:AA:AA'

The function ls(ARP) shows you more available options.


Site password being used to secure ZIP download, are they storing my password in plaintext?

First, would this now allow for easier dictionary attacks? If a malicious actor where to get a hold of the zip file, they could run a dictionary attack against it with no real knowledge right?

Yes. They could perform an offline attack, with no limitation on number of attempts.

Second, are they storing my password in plaintext (or another recoverable format)?

Most likely, yes. They keep the password in plaintext around. At least from the point you enter it to log in up to the point you download the ZIP file, but probably it's stored plaintext in the database.

It seems unlikely they would be able to use the same hash across both the site and the zip file they are sending out, right?

In theory, it could be possible if the site and the ZIP use the same KDF. I don't think anybody in their right mind would do this. And even if that were the case, the ZIP files still contain your password hash and still allow an offline attack.


Cracking a MD5 hash from numerical input

While it is considered as insecure, MD5 is still considered as preimage resistant, so your best option is still brute-force.

Knowing some information about the input will help you in the brute-force process, but there's no known weakness which might help you.


This scheme, however, doesn't deal with the fact, that the agent is not secure against physical attacks, in case of which, the public/private keys would get stolen from the agent. Then anyone could imitate the agent and send registration requests with the stolen keys.

If the attacker has physical access to the agent computer, then the attacker can operate the agent computer, and send any requests in its identity.

  Is there a way, to know, undeniably, from the communication, that the party is the agent, without storing cryptographic keys on the agent locally?

Well you should still use cryptographic keys to secure against virtual attacks, but there may be other solutions that can be used in addition to cryptography.

Some ideas that come to mind.

You could require the connection to originate from a specific IP address that is only available by connecting to the network cable at the Agent station. In this way, the attacker would have to forge requests on-site, and could not simply copy the keys for later use elsewhere.
Depending on your Agent computer, it is possible that attacks will require interruption of the OS to access internal data. If that is a necessary component of the attack, then you can use a continuous communication channel to detect when the OS is terminated. The server can assume it is an attack (not knowing) and the credentials be disqualified.

Administrator override can be used to indicate the interruption was a technical issue (such as internet connection issue or router restart) instead of an attack, in which case the credentials can be qualified again.
Use a separated One Time Password device that the user keeps in his possession. YubiKey or GAuthenticator are possible implementations of this. This is not a silver bullet, but would make it more difficult for an attacker to forge a request, as he would have to install a program that waits, and then eventually makes use of the One Time Password. Your server can enforce Replay Attack prevention to make the attacker less invisible.

Again, your options are limited when the attacker has physical access to the machine, but perhaps these will help. Welcome to Security Stack Exchange!


The default mode will be  MODE_ECB as detailed in the documentation. The different modes have already been described in this answer.


Was coerced into setting up 2 Google Phone Accounts and don't know how to delete them

Ok, so firstly we need to understand, what they are after is your number so they can use it for google voice calls and mail most likely. You did not create two voice accounts, what you did was attempt to link your phone number to someone else's voice account twice. What i think happened here is that the first time they messed something up or google got in their way, so they opted to try a second time. They may or may not have gotten it the second time we are not sure.

This scam will almost always appear in the form:

I want to buy your item from [marketplace]
I cant wait and must call you now
I need you to input 2 digits because im using X

X being conference calling, google voice, or any other reason to input a code to connect to somone. If you input the code you linked your phone to their google voice account and they can do things on your behalf.

The solution here is to create your own google voice account and link your number to that account to stop them from being able to use it any further, since you control the phone you are the only one with the ability to do this. i.e. they cannot get it back without getting you to re-link to their account.

First go to Google Voice and start the process. Select your device:

Then you will be brought to a page with further instructions. Follow them. Eventually you will be asked perhaps to login to an existing google account, do so, or create one if you don't have one.

Once you are ready to link your number you should be able to go to your google account, get into your voice account and select the following:

At this point it will ask you to which number you wish the account to be linked. Type in your scammed number. You will get a call from the exact same number (which is, 202-455-8888, I believe) you got before asking for the exact same kind of 2 digit code, which i assume will be sent to your email or via text, or they'll give it to you over the phone and you'll input it on the site. Do that.

You may also be able to see here if you were too late in avoiding their use, but im not sure, as i don't know if account transfers preserve history.

However, any previous links to your number at this point should be unauthorized for use.

At this point it may ask you to port your number, do not do so. Porting will issue a stop on your current phone contract, not something you may want, you will create a new phone number to use with google voice.

Use the google voice number for online selling in the future (might as well), this has the benefit of not giving away your real number to anyone while selling things.


How to check if computer is controlled remotely

If your computer is being remotely accessed, you have no idea how deep the infection goes. Nuke from orbit is the only way to go.

As for detecting remote access programs, there are offline scanners you can run from many vendors that look for known remote access malware. But, of course, that only covers known malware.

You can listen on ports and list processes, but malware can also be time-based and only run at certain times or when certain event occur. Malware can also attach to existing legitimate processes, so that they look completely normal.


Authentication for external applications

The only way to have a secure authentication system for a company that can still function while the corporate network is unavailable, is to not use the corporate network.   Consider hosting this service in the cloud,  or having a cloud based hot-backup.

Having a copy of the authentication database on each device is vulnerability, and a clear violation of CWE-602.  By definition this system is giving a user all of the keys to the kingdom.  The database must be accessible to authenticate a user off-line, and at this point an unauthenticated attacker has access to all of the data stored on the device (buss sniffing, attaching a debugger to the authentication process or a cold boot attack,  and there are other attacks...).

Attempting to "encrypt the database" is a manifestation of the DRM problem,  which has no solution.  (The only thread holding up DRM is the DMCA.  The DMCA will not protect an insecure database from compromise.)


nikto's results differ from other vulnerability scanners , is it more or less accurate?

Why are you looking for the best "starting point"? They all test for different things and each behaves differently. Regardless of the tool, you still need to verify the results, and each tool will be better at some sites than others.

The best one to start with is the one that offers the best value to you for that web application. Then run the others knowing the weaknesses they might have for your application.