Convergence - an SSL replacement? Today, Moxie Marlinspike, a security researcher famous for his research on Android and SSL and related protocols (author of sslstrip/sslsniff), released "Convergence" which says is "an agile authenticity replacement for SSL" and attempts to address the problems the that are created by the idea of trusted Certificate Authorities.

The website that features a firefox plugin (client code) and a notary (server code) is here: http://convergence.io/

It is also open-source on github.

What are the pro's and con's of Convergence as an SSL replacement?

Just to be clear, it's explicitly not an SSL replacement.  It's a replacement for CAs, with the explicit design goal of not forcing some giant IPv6-like "change the world" rollout.  It's based in large part on earlier work on solving the SSH Host Key validation problem - see http://www.usenix.org/event/usenix08/tech/full_papers/wendlandt/wendlandt_html/

In Convergence, there are some number of network topologically distant "Notary" services, run by a diverse collection of different organizations.  The (self-signed) SSL certs for each of the Notary endpoints are baked into the browser.  When the browser hits an https site for the first time, it fetches the cert and then dials out to all N of its Notaries, and says "I went to talk to www.example.com:443 and got back this SSL cert.  Is it good?".  The Notaries issues a yay or nay.  If all the Notaries say "yay", the browser caches the cert up to the cert's natural expiration date.  On subsequent requests to www.example.com:443, the browser compares its cache against the cert it just received.  If there's a mismatch, it dials back out to the Notaries again.  Since sites don't do cert rotation that often, and browsers can do super-aggressive cert caching (and key-rotated certs get cleanly invalidated from the cache), it's not an inherently un-scalable solution.

The Notaries are free to set whatever policy they want for what constitutes a good or bad cert.  The suggested ones are "Notary's servers poll site", "Notary consults the EFF SSL Certificate Observatory", "Notary checks for what cert is on file in DNSSEC", or even "Notary does traditional CA validation".

I think it's the most unintrusive solution to the CA problem ever.  Aside from convincing MS/Apple/Google/Mozilla to jump on it (and the Citibank problem), there were two issues that bugged me.

First one is captive portals (e.g., airport or hotel wifi).  He handwaved past that a bit, and proposed using DNS as a fallback protocol to communicate with the Notaries.  But, there are numerous captive portals that'll just eat DNS records other than A & CNAME.

Second one is what's the financial incentive to run a Notary?  To scale, there are going to have to be tons of these things.  Some orgs might run them out of the kindness of their hearts, much as DNS roots are done, but I think the architecture of DNS scales quite a bit better than Convergence.


Why using bitmasking in Blind SQLi? I'm following this tutorial on Pentesterlab about SQLi, and they're talking about Blind SQL. From what I thought blind SQLi was needed when you don't see (error) output from your target, and you can only use fase/right/slow/fast to see if your query is true or works.
But in that tutorial they start about bit masking and I don't know whatever.
I know that bitmasking exists out of:

Extracting: AND (used in this tutorial)
Setting subset: OR
Toggling: XOR

And 'AND' works example like this:

MASK: 100110 VALU: 101010 RESU: 100010

Only '1' where value and mask are '1'.
However, how is this used in Blind SQLi? And why that script they use in the tutorial?
tl;dr
Why do they use bitmasking in Blind SQLi, I guess I don't understand Blind SQLi completely.

I thought blind SQLi was needed when you don't see (error) output from your target, and you can only use fase/right/slow/fast to see if your query is true or works.

Correct, in a blind SQL injection you can only evaluate if the result of a query is true or false.

So, how would you fetch a value from the database if you can only ask yes/no questions?

You would surely ask for each letter separately. But that would still be at least 62 possibilities (assuming a-zA-Z0-9) per character. Therefore, the idea presented in the tutorial is to ask for each bit individually. This way you need exactly 8 queries per byte to determine its value. So all you do is transform the value you want to read into binary and successively ask for every bit if it's 1.

Say, you want to retrieve the value "secret". So you start by extracting the first character:

substring('secret',1,1) -> 's'

Then you get its ASCII value:

ascii('s') -> 115

Now you apply a bitwise "and" (&) to isolate the value of the first bit:

115 & 1 -> 1

  1110011
& 0000001
---------
  0000001

The result is 1 which makes the statement true.

If you apply this method for every bit of every character of the value you want to read, you'll eventually get the entire string by just evaluating if your queries are true or false.


Way to hash passwords client-side without javascript? I'm working on implementing a basic login system (I know, don't roll your own security, blah blah blah) using PHP and MySQL. However, I don't want the user to need to have JavaScript enabled, meaning almost all of the heavy lifting should be done server-side. So I want to hash the user's password before sending it to the server. Basically, I don't want to rely solely on https and ssl to prevent MTM attacks. But I also don't want to use JavaScript for client-side hashing.

I can I ensure that the data I send to the server is hashed or otherwise not plaintext without relying on JavaScript?

You're not going to like any of the options. The reason people disable JavaScript is precisely because of its ability to execute all sorts of instructions; the other options for client-side execution (flash, java applets, silverlight) are certainly going to be disabled by someone who disables JavaScript, because they're even more powerful. Your two requirements are in conflict, so you need to decide which one is more important.


Cipher suite selection for compatibility with http/2, and TLS 1.0-1.2 I have been attempting to configure my site to have http/2 support, but I kept having to remove cipher suites because of the blacklist. Eventually, I got the list whittled down sufficiently.

The problem, however, is that I only have a cipher suite compatible with TLS 1.2 now. I'd love to use this, but it's not practical as it breaks Safari versions as new as shipping with OS X 10.10 because those only support CBC suites.

Any thoughts as to what to do to have reasonable compatibility, yet support HTTP/2?

Presently, the list is AESGCM+EECDH:AESGCM+EDH:!SHA1:!DSS:!DSA:!ECDSA:!aNULL

Have a look to the list of suites (and the order) supported by https://www.shimmercat.com , I'm pretty sure the site works in Mac OX X and iOS. You can use qualys SSL tools to get the list.


Is this way of using Authorize.net's CIM PCI compliant? We have a webapp where Authorize.NET's CIM and AIM are used for payment operations. When user buys something at first time he enters his CC number and other billing information at our site. This information is entered and transmitted from browser to our server through non-SSL connection. Other PCI-DSS rules (such as password restrictions) are also not satisfied by the site. Then this billling information is transmitted from our webserver to Authorize.NET's servers. CC number isn't stored by ourselves but we store (in not encrypted way) CC expiration date, 4 last digits of CC number, first and last name of cardholder. When user purchases something at 2nd time, he should just choose to use this existing credit card to buy something.

API Login ID and Transaction Key are also stored in not encrypted way.

Is our site PCI compliant? Is it a correct way of using CIM?

Edit: Will it be enough to just switch to site-wide SSL and not store CC expiration date and 4 last digits of CC number?

If you're transmitting credit card information through a non-SSL connection to your servers, you're not PCI-DSS compliant.  It is a requirement all personally identifiable information is transmitted through secure (encrypted) connections.

Regarding the rest - the storing of unencrypted information: expiry date, etc - the answer depends on your company's classification under the PCI-DSS rules; if a small company, there are less stringent requirements.

I recommend reading the PCI-DSS documentation thoroughly before proceeding with this. It can be found here: https://www.pcisecuritystandards.org/security_standards/documents.php

Note: once you think you're compliant, you should have a compliance test run by an external auditing company (I use SecurityMetrics but they're not the most fun company to deal with). They are then usually done quarterly to ensure continued compliance.


debugging why TLS fails between openssl and some SSL sites I have an old CentOS 5.11 system running OpenSSL 0.9.8e.  I am able to connect most SSL sites with no problem.  However with some sites like www.looklinux.com, if I try to connect I get this error:

openssl s_client -connect www.looklinux.com:443
CONNECTED(00000003)
27080:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure:s23_clnt.c:586:

Now, from doing

openssl s_client -connect www.google.com:443 | grep -i "protocol"

I see Protocol  : TLSv1 in the output.  And from
https://www.ssllabs.com/ssltest/analyze.html?d=www.looklinux.com&latest
I know that www.looklinux.com supports TLS 1.0, 1.1 and 1.2.  So it seems the client and server share at least one compatible protocol (TLS v1) and that's not the problem.  Am I right so far?

Then, what's going wrong and how can I fix it?

When I run it with the -debug flag I get:

openssl s_client -connect www.looklinux.com:443 -debug
CONNECTED(00000003)
write to 0x872a198 [0x87665b8] (88 bytes => 88 (0x58))
0000 - 16 03 01 00 53 01 00 00-4f 03 01 5b 05 ff fc 97   ....S...O..[....
0010 - 78 87 a5 97 77 11 57 60-1b e0 ae 9f 81 8c c6 c6   x...w.W`........
0020 - 15 3c fb 0b ef 3e d7 20-8a 83 3b 00 00 28 00 39   .<...>. ..;..(.9
0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f   .8.5.......3.2./
0040 - 00 05 00 04 00 15 00 12-00 09 00 14 00 11 00 08   ................
0050 - 00 06 00 03 00 ff 01                              .......
0058 - <SPACES/NULS>
read from 0x872a198 [0x876bb18] (7 bytes => 7 (0x7))
0000 - 15 03 01 00 02 02 28                              ......(
1678:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:586:

This post:
https://stackoverflow.com/questions/48983918/authorize-net-gem-tls-1-2-compatibility
suggests that sometimes an older version of OpenSSL is just not compatible.  Is it easy to explain what it is that the older OpenSSL can't do?  And is there really no workaround?  I'm wary of "updating" it by building OpenSSL from source, because instructions to build from source usually have errors or omissions, where an expert reader knows what the instructions were supposed to say, but I follow the directions exactly and get hosed.  So I'm hoping I can fix this by just installing an extra certificate, or something.

This problem is not related to certificates in any way and cannot be fixed by a certificate.

The SSLLabs report shows that server supports only suites using ECDHE_ECDSA keyexchange, i.e. Elliptic Curve Cryptography. Upstream OpenSSL 0.9.8 did implement ECC, but disabled it by default and you had to read the source to find the magic word ECCdraft to enable it. However, RedHat and therefore CentOS removed (all) ECC from packages built before about two years ago, so that probably won't work for you. You can fairly easily see that the list of offered suites in your ClientHello (hex offset 2E to 56) does not contain any bytepairs in the range C0xx where all the ECC suites are.

In addition, as noted on the SSLLabs report, "This site works only in browsers with SNI support." and OpenSSL does not send SNI by default; you must specify the option -servername $hostname -- which does work in 0.9.8.

However, my 0.9.8zg with ECCdraft and -servername still gets alert 40. The only difference I can find between that and 1.0.0s (with -servername) which does work is that 1.0.0 sends the pointformats (0xB) and curves (0xA) extensions and 0.9.8 does not -- but according to rfc4492 they are supposed to be optional. So even if you had an un-nobbled 0.9.8 you might be out of luck.

I have never had any problem building OpenSSL itself from source on any decent Unix; it's actually one of the simplest packages to build I've experienced. However, you would also need to rebuild everything on your system you want to use the updated OpenSSL, and depending on what those things are that could be much more difficult, especially where source changes are required, as they were in some cases going from 0.9.8 to 1.0.x (and much more from 1.0.x to 1.1.0 if you wanted to move up that radically).

Depending on what you are doing, you might be able to route your traffic through an external SSL/TLS proxy, like squid+bump, that accepts the grimy faded old TLS (or even SSL) you can do, and relays your data to and from other systems using shiny glittery newfangled TLS.


Does it serve any purpose to have a CRL with the next update scheduled for 25 years in the future? What purpose does it serve to have a CRL with nextUpdate set to +25 years?

A CRL issued by the root of an operating Certificate Authority

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: ..........
        Last Update: Jun 19 21:19:12 2019 GMT
        Next Update: Jun 12 21:19:12 2044 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: ..........

            X509v3 CRL Number:
                5
No Revoked Certificates.
    Signature Algorithm: sha256WithRSAEncryption

Well, the CA is for public on-line use. It has the following structure:

ROOT
+--INTERMEDIATE  -- a CRL signed by ROOT
   +--END_ENTITY_AUTHORITY  -- a CRL signed by INTERMEDIATE
      +--END_ENTITIES  -- a CRL signed by END_ENTITY_AUTHORITY

Only the CRL for END_ENTITIEs is being refreshed, the other two are similarly set to refresh in far future just before the signing certificate expires.

Mike Ounsworth:
From what you say, after reading some of the requirements to get accredited in the operating context, looks like a regulatory requirement fulfillment.

That could be that an IT person said "I don't want to deal with this", and did the CA equivalent of "Postpone reboot for 100 years".

Or it could be a CRL intended for an offline environment where the clients validating certs will not have access to the internet to fetch a new CRL. For example, IoT devices inside a car that are communicating with each other over TLS.

It's also not uncommon that the root CA in a hierarchy will be "offline", ie it issues certificates to the intermediate CAs, and then gets shut down. The issuing CAs create CRLs regularly to revoke end-entity certificates, but since a compromised issuing CA would create much larger problems, so it's not worth the effort of waking the root up regularly to publish a CRL.

Either way, it means that this CA doesn't really have the ability to revoke the certificates it issued because clients won't try to fetch a new CRL until Jun 12 21:19:12 2044 GMT.


Network scan across multiple subnets and output list of names and IP's We have multiple sites with multiple subnets. We have mandated that the admins at those sites enter DNS names for all devices that exist on the network. (anything with an IP gets a name) I want to be able to audit this and make sure this has been done.

I am able to run an individual network scan on each subnet but that takes time. I would like a way to kick off a scan that runs through all subnets once a week and gives me an output file with a list of names and IPs. (preferably csv) I have tried to do this nmap but getting a nice list of IPs and their corresponding names is not easy.

The nmap tool combined with some scripting would definitely be able to do this.

Read the nmap book Chapter 13. You might find the "grepable output" is of use:
https://nmap.org/book/output-formats-grepable-output.html

This chapter even gives ideas for cutting the file into different fields.

Scanning multiple subnets is straightforward. You can feed nmap an "input list file" or you can specify multiple targets on the command line:
enter link description here

As another poster noted; it'd be helpful to see what you've tried already.


Why is my web site being scanned for license.txt, and should I be worried? Lately I am seeing multiple daily 404s for variations of "license.txt", e.g., "wordpress/license.txt", "blog/license.txt", "old/license.txt", "new/license.txt". Here's a little snippet of slightly redacted logfile to illustrate:

5.189.164.217 - - [17/Apr/2020:11:12:30 -0700] "GET [redacted]/wordpress/license.txt HTTP/1.1" 404 562 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" etc.
[...]
158.181.48.29 - - [17/Apr/2020:14:46:47 -0700] "GET [redacted]/w/license.txt HTTP/1.1" 404 554 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" etc.
[...]
178.254.50.202 - - [17/Apr/2020:18:45:12 -0700] "GET [redacted]/blog/license.txt HTTP/1.1" 404 557 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" etc.
[...]
217.11.48.184 - - [17/Apr/2020:22:51:10 -0700] "GET [redacted]/b/license.txt HTTP/1.1" 404 554 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" etc.

This specific day the IP addresses all appear to originate from Germany, but this is not the case generally.

Why these repeated GETs for variations license.txt? Is there some known vulnerability being scanned for here? Like if a site responds with a certain license.txt, that is a sign to the client that there's some exploitable vulnerability? Is this something to worry about?

That's just some normal Internet background noise from automated scans, and as they result in  404 Not Found, you shouldn't be worried. The license.txt, readme.html etc. are scanned because they may contain version information, which may lead to finding some unpatched vulnerabilities.

That's not the only place such information could leak from: <meta name="generator" might contain version information, WordPress adds ?ver=X.Y.Z parameters to linked CSS and JS files etc. You could remove such hints, but the best solution would be updating the core, all plugins and all themes regularly, and possibly automate the updates. (Not that you'd even have WordPress installed, but the same applies to any CMS & webapp.)


Is there a need to image the hard drive when using a write blocker? Forensics books often recommend working on an image of the hard drive instead of the original drive.

Should I take this precaution even if I use a write blocker?
If so, why?

Because normal read operation on a disk presenting error (physical or logical) may cause data corruption, destruction and even writing to recover bad blocks.

You have to keep in mind that even the read operation may lead to physical damage or data modification.


Hardware-Based Password Manager I'm trying to improve my password management, and I have a vision in mind for a solution. However, I'm having a problem putting it all together or finding a product(s) that fits.
First I would like to find out if my overall specification/strategy is workable?
Baseline (non-negotiable) requirements:

A password manager with an encrypted (AES-256 or better) local-only password database/vault.  No cloud storage: so services like LastPass etc. are not going to work for me. (Password manager in the sense that all account passwords are accessible from a single master password)
Installable / integrated onto a hardware-encrypted USB-3 thumb drive, preferably one of those with a numerical keypad on the side of the thumb drive that unlocks the drive before inserting into a USB port. The password manager software runs directly from the thumb drive (Windows minimum, but Windows + Android preferred) without any software installation required onto the host system.
Ability to backup the password database/vault (in case the encrypted thumb drive gets lost or stolen).

Feature requirements (really, really want these, too):

Can generate randomized passwords for new accounts
Can autofill login ID and password fields in a browser window without the need for copy/paste (and therefore avoids the security holes involved with Windows clipboard).

Next-level features (all above could likely be accomplished with KeePass + hardware/keypad encrypted thumb, but the below would bring the overall security to the next level - if this is achievable and a product(s) exists...?)

Multifactor authentication (like U2F) of the password manager software/vault itself: the encrypted USB drive itself serves as the hardware token that allows the software/vault to unlock (something along the lines of a Yubikey).  That way if the password vault file itself is copied from the thumb drive (from across the network, say at work), and they grabbed my master vault password (for example a keylogger), the vault still could not be unlocked / unencrypted because they wouldn't have the physical hardware token serving as the 2nd authentication/decryption factor.
And to really ensure a robust solution, the USB drive would adhere to the military spec for encrypted drives (FIPS 140-2 Level 3 compliance, incl. testing by an independent lab)

My last arrangement was close: the Ironkey (before the company was purchased by Kingston).  It was a FIPS compliant encrypted (USB2) drive with onboard proprietary password manager software.  But the password manager has been dropped from the product line, leaving it (basically) just an expensive hardware encrypted thumb drive.

As you wrote, 1-5 can be achieved using KeePass + thumb drive.

As for point 6, It seems YubiKey already thought of that. You can use YubiKey or other HW token with KeePass using the OtpKeyProv plugin. However, I could not find a detailed explanation of how it works and it does not seem to me as very secure. I have a feeling it could be bypassed rather easily by a more advanced attacker.

There are plugins for KeePass that allow use of RSA keys, but I am not convinced they are usable with a HW token. Check (here, here and here)

The RSA key approach if implemented correctly would be very secure and would protect against the theft of the password vault from unlocked thumb drive.

For point 7, just pick a good USB drive, maybe the one recommended by Steven. But honestly, the thumb drive will never provide significant increase in security.

Final note: KeePass can be used on android, but I don't believe the plugins can be. So using 2FA would be at the cost of using it on Android.


Are there any potential complications with these secure baseband ideas? So I have been working on some ideas for securing cell phones from baseband level exploits and I was wondering if there are any potential complications with these solutions such as practicality or functionality.

First idea I had in mind was simply removing the Baseband OS from the processor itself or at least putting hardware level restrictions on what it is allowed to access. (Such as only allowing it to access the modems and phone antenna and such. Everything else would only be controlled by the application processor.)

The other idea was to place a Secure Cryptographic Module on the IO paths that transport data to and from application processor to the baseband. Or into the baseband processor itself. So that any and all data, voice, SMS, regardless of what cellular protocol is used be it 2G, 3G, 4G etc is enforced to be encrypted before it even leaves the device and is sent over the airwaves. This way there would be no way for an interceptor to be able to read anything that is captured regardless of how they exploit the device. There would of course be no way to turn this encryption off. It is always on.

The encryption would be done with a stream cipher that uses 256 bit keystreams and IVs.

So the question is, would there be any possible complications with implmenting these solutions that would interfere with the functionality or practicality of the phone?

4G LTE is already encrypted:
https://security.stackexchange.com/a/21400

Doing additional application layer encryption to cut out baseband malware would involve additional layers of key exchange and transport encryption management on the phone and the tower.  This would create additional expense.

The problem is better solved by using end-to-end encrypted application protocols for communication rather than trying to add additional encryption to the largely already sufficient link layer encryption.


Aes encryption algorithm life time How many years from now will we stop using aes encryption algorithm, as of now aes seems to be virtually immune to brute force attacks and not showing any weaknesses, will quantum or optical computing spell an end to aes?
Sorry if any mistakes in question or sentence formation
Thank you

A quantum computer, if it ever exists, ought to be able to explore a space of N possible keys in time √N. I.e. it could brought down the cost of brute-forcing a 128-bit AES key from the technologically infeasible 2128 down to the much lower but still very substantial 264 -- it will still be quite expensive, especially for a machine that does not exist yet. Note that this contrasts a lot with quantum computers trying to attack a RSA or DSA key: keys for asymmetric algorithms are mathematical objects with a lot of internal structure, and "breaking" them amounts to unraveling that structure; AES keys do not have any such structure, they just are bunches of bits.

Decoherence is the biggest hurdle with quantum computers; to build a QC, you need to put together and entangle "qubits", and make them transition between states without losing their links. To make an analogy: imagine that you are trying to put in the same room a thousand hip-hop dancers. They must all make the same moves in perfect unison. The show stops as soon as any one of them begins to make suggestive gestures purporting to characterize the morality of the ancestry or one of his fellow dancers. If you can avoid that for a full month, then congrats ! You have a working quantum computer. All you then need is to keep it going for a century or so, and you will break AES.

Optical computing does not even reach that level. A "fully optical computer" is classical in nature; for such a computer, AES brute-forcing is still a 2128 effort.

There used to be some hopes about faster computers by using optical gates, based on some preliminary analysis about bistable optical elements that could switch between states about 100 times faster than the corresponding electronic gates. This, however, does not translate to 100 times faster computers:

These measures were from more than 20 years ago. In the meantime, electronic gates were much optimized, and the gap has shrunk.
In modern computers, the gate switching time is no longer the bottleneck; what limits computing speed is the time needed to convey the information from one gate to the next. The problem is the speed of light. An optical computer does not solve that, since light goes, after all, at the speed of light. At best, a fully optical computer can help a bit in reducing the average path length between two gates because light rays can cross each other freely. Don't expect too much of a boost, though.

Moreover, even if you could make a computer that is 100 times faster than existing technology, then you would gain less than 7 bits in brute-force (because 27 = 128). A 2121 effort is far beyond what can be done with existing and foreseeable technology.

We are still using DES, if only as part of Triple DES, despite the publication of AES as a standard in 2001, and the deprecation of DES. Old technologies never die out; at one point we begin to use new ones, but not as a full replacement. Therefore, one may surmise that we will use AES forever, for (at least) backward compatibility.


Learning the role of intruder legally Possible Duplicate:
  How can you become a competent web application security expert without breaking the law?

I was reading this article earlier U.S. government hankers for hackers
, and wondered how does one train now a days? In the article there is a quote:

  "They need people with the hacker skill set, hacker mind-set. It's not like you go to a hacker university and get blessed with a badge that says you're a hacker. It's a self-appointed label -- you think like one or you don't," Moss told Reuters.

The question is, how does one gain the skill set necessary to become a hacker with so many people being busted everyday for smaller things. A person could have the best intentions, and end up in jail. As a site for security professionals, how would you hone your skills from the attackers point of view?

Once upon a time, some people tried to encourage discrimination between the terms "hacker" and "cracker".  There is nothing inherently illegal about "hacking"; if you've ever pulled a toaster apart to see how it worked you've hacked.  (Fully legally, so long as it was your toaster).

Likewise, the hacker mindset does not depend upon criminality.  It is an openness to new ideas, a willingness to take things apart and to dare to put new things together.

As it turned out, people with this sort of intellectual flexibility were drawn to, and good at, breaking systems, which is why people say "hackers" today to cover that sort of thing.  (And why the effort to separate that activity to the term "crackers" failed).

@Robert David Graham and @wax eagle make excellent points.  Playing around with things is how you become a hacker, and if you want to play around with security, you can do it with your own systems or with permission and stay legal.

With apologies to @Mike Samuel, there are many classes that teach hacking skills, but there are no classes to teach someone to be a hacker.  A true hacker is usually impatient with being taught; it is their willingness to teach themselves that makes them what they are.

(With that said, for the purposes of becoming a talent the gov't would be happy to hire, classes will do you just fine).


Hiding version - valuable or just security by obscurity? Many automatic security scanners have built in rules that alert on the presence of software version, and in many security lists version exposure to arbitrary person accessing the system is mentioned as one of the security problems.

So my question is - is it a real problem and is hiding the version adds anything real to the security?

The arguments for it say that hiding version makes harder to use targeted exploits, however most attackers now have automated exploit kits which take no time to run hundreds of exploit attempts against the target, so the difference is next to zero for an informed attacker. And one that is not informed will not know how to use the version information. Hiding versions also makes it harder to self-scan for left-behind vulnerable installations.

I also see that this practice is widely ignored - for example, the very OWASP page that describes this as security technique openly displays versions of the server software (OS, Apache, PHP) and the Wiki software. But even if you try to hide it, most web applications - especially complex ones - are easily versioned by fingerprinting of various content they generate.

So is it worth hiding version for a web application? Or for any application/OS/platform at all?

The problem with security by obscurity is when you depend on obscurity to get security. If that's your only or main form of defense, you have a problem.

With that said, obscurity can add security to a system already using better strategies for security. There is no reason to expose that information, so you should not. It's useful information for an attacker, so you should certainly hide it whenever possible. The problem is when you start thinking along the lines of "well I hide this information, so no attacker can find out and use it to attack my system, so I'm safe."

Your system should be secure regardless of whether that information stays secret or not, but you shouldn't do the attackers any favors by releasing it.


Enabling wifi or bluetooth before user login in Linux What would the security implications be of enabling and using wifi and / or bluetooth before a user logs into the system in a Linux box?

Thanks for your help!

At a bare minimum, you expose the account the service runs as. If the service is subject to attack, then that becomes a vulnerability.

This is no different from exposing any other service, except that it is exposing a communications channel. The important question is, "what else on the box is using that communication channel?" You need to chase down the cascading services.


IDS across separate AWS accounts I have two separate AWS accounts and I would like to a Vuln scanner/IDS on one to scan another.

One environment is a regular AWS account and the other is in AWS Gov Cloud.
Due to limitations within Gov Cloud I was only able to install my IDS on the regular AWS account. I would like to scan my machines within the Gov Cloud from the regular account.

What's the best way to do this?

I was thinking about attaching public IP addresses to my Gov Cloud instances and creating a SG to only allow my IDS access. What is the best practice here? Is this an acceptable solution?

Note: I realize installing the IDS within Gov Cloud is ideal but the IDS license is already purchased and the AMI can only be shared with a regular account.

I would first try to contact the vendor and explain to them what occurred so that they would re-do your license to allow you to move your scanner to where it should be. Most, if not all would do this.

Secondly, I don’t want to misinterpret things here, but when you state “due to limitations on Gov cloud” I am interpreting this to mean you do not have appropriate permissions. I am going to err on the side of caution with this statement: Make sure you have full authority, rights, and permissions to install something on this instance otherwise you are likely breaking laws. I can see no reason for you not to have permissions if it is part of your role.

Now on to the IDS question/portion. Most IDS portions rely on logging information (event logs, syslogs, etc) to generate “events.” These events are thereby acted on (an alert is sent, alarms triggered, etc). Your goal seems to be to get this data from point A to point B. The optimal of doing this would be to create some form of encrypted communication session to transport data to and from each machine. To do this, I would use a VPN session/tunnel as opposed to putting a public address on a machine that likely shouldn’t have a public address.

The downsides of putting on a public address is that you make your machine a target. In doing so (configuring a public address) you would then need to create two firewall rules on each location to minimize connectivity from unauthorized locations. This creates more work, more configuring, more room for error.

If you CANNOT get the vendor to address changing the vulnscanner/IDS licensing, I would do the following:

IDS SYSTEM —> VPN TUNNEL —> GOV MACHINE

This encrypts data to and from, and depending on how you configure your connection (site to site, roaming) will allow you to avoid creating firewall rules on both ends. Determine what it is the IDS is looking for (syslog, event logs, etc) and configure the client to send those to the IDS server in a secure fashion (via VPN). It is not that complicated.


How often should I reset my users' session cookies? I am working on a Rails application where I reset the session upon logging out and each successful login, as well as when the user IP address changes.

Would resetting the session (changing the session ID cookie) after each user request significantly reduce chances of successful session fixation attacks?

Session fixation is an attack where the victim using a vulnerability fixes a session id in the victims browser and then when the user authenticates himself the application does not provide a new session token.  Because of this, the attacker also get authenticated using the victims id.

Session fixation attack won't be possible if the application provides a new session token when logging in and out.  Your current solution is fine and changing session tokens in each request is over-engineering it.  It may also inconvenience the user if they switch networks (such as on a mobile device) if you invalidate it by monitoring the IP.


Secure Spring FrameworkUser Management I got asked this question:

"Any decent reusable / plug-able Spring user management systems (registration,  change pwd, reset etc)?

How do you guys do authz in Spring, including managing those roles in ui?"

My first thought was http://static.springsource.org/spring-security/site/ but I haven't used it in a while and am not sure if it is easy to implement and deploy.

Any good recommendations?

I use Spring Security extensively, but it's intended to solve a different set of problems than the ones you cited: registration, change-password, reset.  You'll still need to handle all that yourself.  Spring Security is a very effective tool for handling authentication, authorization, and access-control.


Security in memory and between local windows processes over localhost I have a windows application that runs in 2 processes and communicates over localhost network port.

This application can hold secrets, such as a web cookie.

I'm trying to think through the security vulnerabilities.

My impressions:

With modern virtual memory, applications have protected execution space (DEP) by default, so a developer doesn't need to do anything?
Memory ACLs only protect you from malicious code running as OTHER users. If Bob installs my app and a malicious app, the malicious app running as Bob could access my apps memory.
ASLR is for buffer-overflow exploits and doesn't apply to read-prevention.
The localhost call is not secured against other users on the computer, anyone can listen to this. It would be more secure to use another ICP medium.
If the localhost network port is decided at runtime, it is easier to MITM than if it was fixed.
Windows provides a user key-store that might be a good place to hold secrets. But if the application holds the secret in RAM it is still potentially readable by other processes.

Please let me know what I've got wrong. Thanks!

TL;DR: You almost certainly should switch to more secure IPC. Beyond that, you probably don't have a great threat model.
I'll respond to your numbered points first, then write a general answer below:

All recent Windows versions support DEP and all recent Microsoft compilers (and probably most or all third-party compilers too) will automatically mark their output as DEP-compatible (/NXCOMPAT). It is possible to configure Windows to override this flag (in either direction - using DEP even without the flag, or not using it even when present) but the default configuration will use the flag. Note that DEP doesn't really have anything to do with virtual memory per se - you could in theory implement it on a system that doesn't use virtual memory, although I don't think any such system has it - and has nothing at all to do with other processes accessing your memory, so you might want to make sure you understand what DEP (and virtual memory) are.
Virtual memory prevents accidentally reading another process' address space. A process can request access to another process' memory (by calling OpenProcess with a read permission). This will be subject to an access check: the caller's security token (a kernel-mode data blob describing the process' identity) and requested permissions are checked against the target process' ACL. By default, this ACL forbids most permissions (including accessing memory) for other users, but allows code running as the same user (and not at different elevation levels, integrity levels, or using any other sandboxing) to take full control. So yes, if your user is running malware, your app is hosed.
ASLR (like DEP) is a mitigation for a broad class of memory corruption vulnerabilities (including buffer overflows), and has nothing to do with inter-process memory access (except for stuff like "you can't hardcode the address you're reading, because the address space gets randomized"). Also, unless you have to use native code (C/C++) for some reason, instead of a managed language (C# or anything else on the .NET runtime, or Java, Python, etc.), you shouldn't even have to worry about this class of attack unless you're doing silly things with the memory management (or native code interop). Also (like DEP), ASLR is enabled via an optional (but enabled-by-default, in all modern versions) flag on the binary; all modern libraries should have it (and it's possible to force Windows to use it even if the binary isn't marked as compatible) but even a single library not using ASLR can be enough for an attacker to turn memory corruption into arbitrary code execution. Also, even with both ASLR and DEP, sometimes an attacker can still extract memory contents (or just execute arbitrary code); it depends on the vulnerability (actually usually on multiple vulnerabilities) in the program or the platform (runtime, OS, CPU, etc.).
Loopback network connections have no inherent security, and are among the worst IPC options for sensitive code. Any malicious code on the same machine (as any user) can potentially compromise the communication by spoofing one or both ends. Additionally, various remote-initiated attacks (such as SSRF) could allow compromising such a system without even being local to the machine. Finally, using "localhost" (rather than a loopback IP address) is less safe, as "localhost" is merely resolved to the current machine by convention and could instead resolve to another machine (though this would be weird) or cause a DNS lookup that a network attacker could spoof (I've seen this one in the wild, though rarely). You should absolutely use a different IPC mechanism. Windows does not lack for them. Named pipes, local domain (Unix-style) sockets, ALPC / RPC, shared memory, mapped files, even things like window messages are more secure than network sockets. Named pipes are the most socket-like option that is compatible with old releases of Windows, but local domain sockets have been in Win10 for a while now and require minimal code changes (assuming you were programming against the sockets API directly; if using some library then the library may not yet support them).
This depends on how you're communicating the port between the endpoints, but generally speaking, not even making the attacker need to figure out the port is just making things easy on them. Again, though, network sockets are a terrible choice for same-machine IPC of anything sensitive. Also, any program using fixed ports will just break if some other (entirely legitimate) process happens to be using that port, so you typically only use them when you must.
The Windows Credential Store is indeed a good place to hold keys, credentials, and long-lived tokens. A stored value is still readable by any other process with the same or strictly-greater privileges as the one that stored it (any two normal processes under the same user, or if the storing process was a sandboxed app but the retrieving process is not). It also means committing the token to long-term storage, which you might be trying to avoid? The Credential Store encrypts its data using DPAPI, which uses a key protected by the user's password (and transparently decrypts the data for any process running under the same user).

What you're getting wrong:
Don't use network sockets for local IPC; seriously, that's almost always wrong unless one endpoint is a web app, and try to avoid it even then. Beyond that, though, you don't seem to have a very complete view of the threats against this system. Reading a secret out of another process is usually not the easiest way to get it, and any attacker who can do that can probably do far worse. You need a threat model, you need to decide on an acceptable level of risk, and you need to mitigate every threat whose risk you will not accept.

Threat Modeling advice below; not so much directly related to the question.
There's a few different approaches to threat modeling, but they all boil down to trying to enumerate the ways that somebody could do something you don't want. One option is to start by listing your potential attackers, all the things you're trying to prevent them from doing, and all the ways they could do them; alternatively, start by identifing all the places that any attacker could interact with the system ("attack vectors") and then for each interaction point, figure out what an attacker can do. There's a few mnemonics for enumerating threats, such as STRIDE (Spoofing, Tampering, [non-]Repudiation, Information disclosure, Denial of service, Elevation of privilege).
For this system, who are your potential attackers?

Admins (or malware running with admin privileges) on the same machine: go back to the drawing board; it can't be made safe.
Other processes running as the same (non-admin) user as the one that started the app: might be possible but will require admin privileges to install and update; if that's a blocker then back to the drawing board.
Apps running as a (non-admin) other user: you're probably fine so long as you switch to secure IPC.
Other machines on the same network, or on the Internet: you might be fine (so far as the "pass secret between local processes" aspect is concerned) as is but should switch to secure IPC anyhow.
An attacker who can access the disk directly while the machine is off (stolen laptop, etc.): if possible, use a full-volume encryption like BitLocker, but if you can't guarantee that (or can't configure it very securely), consider keeping the secret in memory that won't get written to the pagefile and either not writing it to persistent storage at all, or encrypting it with a key provided by the user in some way (password, hardware token, etc.) before doing so (DPAPI works here, although it depends on the security of the user's Windows password and cracking those is pretty easy).
An attacker who can access the RAM directly while the program is or recently was running (an advanced "stolen laptop" scenario): nothing you can do, short of beefing up physical security and/or embedding a hardware security module in the system (both of which are well out of scope for software).

Now, mind you, if the secret isn't that valuable you can probably just accept the threats from some of those actors, because the mitigation is too expensive or inconvenient. Learning what risks to accept is an important part of security.
A few other things that might be somewhere in a complete threat model for a system like this:

Your secret is potentially used for something outside your processes (like communication with a web server); make sure that is secure too.
Your programs are presumably installed somewhere on the machine's disk; make sure the install location is secure (all the IPC and memory security in the world won't do you any good if the attacker can just edit the executable code).
Similarly, if you're storing any data of any sensitivity at all - even if it's less sensitive than the secret - make sure it's stored in a place the attackers cannot access it and, potentially, that it's encrypted.
If the secret is a security token and there's some way an attacker could try to guess it (making requests to a server, for example), make sure it has enough entropy (length of securely random data) to resist brute-forcing, and try to block side-channel attacks (such as timing attacks).
If the secret is used for cryptography (or indeed if you're writing any crypto code anywhere in there), get somebody who knows crypto to review it. Crypto is hard to get right, and sometimes a tiny mistake makes it trivial to totally break the protection.
... and too many others to enumerate, depending on things like "does the program take user input", "does the program send or receive external network traffic", "does the program process passwords", "how does the program update" and so on.


How to secure my REST implementation for an ember.js app I've been searching and searching for what seems days and have not come up with any definitive answer on a solution to my problem.

To explain without going into terrible detail I am building a store, this store does NOT have a cart system, so the user will purchase one item at a time, possibly with a quantity system but that's beside the point, it will also NOT have a login or registration system for users.

In the accepting payments department we are relying on Stripe with some PHP and ajax so handle that end, we have used the before over SSL with great success and I am confident in it's security abilities.

When things get a little fuzzy is when I hook into my backend sever that is serving me json objets referencing products. When a user makes a purchase we will obviously want to remove that many from the quantity of that item in the database. For the time being during my proof of concept portion of this build I have been using Parse and a great Parse Adapter that someone built for Ember.js. It is working great and I can get the items and edit the quantity of them as well. The problem is that it requires that I place a few API keys that could potentially allow people to inspect the javascript, grab those keys and use them to make other REST requests to the server backend.

I haven't done a terrible amount of research in how secure Parse's backend is but it seems seemingly simple to grab those keys and use them like I mentioned above.

For reference here is the Adapter that I am using that will maybe give you a better idea of how it's working.

https://github.com/clintjhill/ember-parse-adapter

I'm really hoping someone can shed some light on this subject because I am at the end of my rope it seems here, I just can't seem to wrap my head around this.

Ultimately, you should not expose API keys to the client, if those API keys can be used to make authorized transactions against the REST API that the client would not otherwise be allowed to make.   Think of it this way, if you needed an administrative username and password to access the REST APIs, would you be willing to put that username and password into the JavaScript that you send to the client?  No, because you'd be making everyone who visits your website an administrator.  The API Keys that allow administrative functions to be performed are exactly the same.

So, if the keys need to be kept secret, keep them secret.  They need to live on the server, and the server needs to make the requests to the backend system using the keys, and then the server can turn around and serve the results of the API responses back to the client, sans keys.


Is it insecure to use PBKDF2 on a SHA1 hashed password? If you already have SHA1 hashed passwords and you're trying to migrate to a better password hashing algorithm, is it less secure to just use PBKDF2 to hash the SHA1 hashes you already have instead of migrating users over when they next log in and hash the password with PBKDF2 directly?

In other words, is there any difference between these two approaches?:

PBKDF2(SHA1(password)) or PBKDF2(password)

The ability to migrate the existing hashes over in one shot would make a migration much easier.

This is a pretty common interim conversion scenario. If you have the luxury of having control over the code that manages authentication and can support both methods simultaneously, this is operationally efficient without sacrificing security, if properly implemented.

Informative reference here.


Secure Azure to Data Centre Web Service Calls via Trusted IP? Background

The company I work for have a system with some data.
This system's hosted in our private data centre.
This system provides some ReST web services.
We're looking to create a website, hosted in Windows Azure, which will call the above system's ReST services.
Users of this website will be authenticated via ADFS (long term we may look to include other options for users outside of our company to be authenticated).
We need to secure the communication between the Azure website and the locally (data centre) hosted system.
Initially we'd like to keep this simple; e.g. allow a trusted IP from Azure to talk to our ReST service.
Longer term we'd been keen to implement something more flexible, such as OAuth to allow other external applications to be plugged in with minimal effort.

Question

Is securing services by IP sensible, or could this be a security risk (especially as we're hosting on Azure, where potentially others may host applications)?
If anyone's done something similar before / can point me in the direction of useful articles, that would also be appreciated.

Securing by IP is a great first step. It severely limits your attack surface. But, as you point out, the source IP in PAAS deployments has limited trust value.

Adding a (reverse) proxy server between the outside world & the inside (local) server will also make things more difficult for an attacker. In business settings, having a reverse proxy separate from the application server also allows you to give the developers & the IT security team their own "box". The proxy server can then be hardened & closely monitored (making IT security happy) without much affect on the application (making the developers happy).

Finally, setting up a secure IP transport (e.g. SSH tunnel, VPN, or HTTPS with a limited set of certificates) between the Azure servers & the internal network will greatly limit the attack surface. This may be difficult with the Azure platform, which is why I have it last.


How do google or facebook know I'm behind a man in the middle proxy? Whenever I'm behind a man in the middle proxy such as burp, and try to access either google or facebook, I get an alert message telling me that the connection is not reliable and blocks the page from displaying.

I'm guessing it has something to do with security certificates. But how do they know not to trust the connection?

These sites set the HSTS header (HTTP Strict Transport Security). If you have visited these site without the Burp proxy before, your browser knows (cached) the HSTS policy and sees a mismatch.

The HSTS Policy specifies a period of time during which the user shall access the server in a secure-only fashion.

  HTTP Strict Transport Security (HSTS) is a web security policy mechanism which is necessary to protect secure HTTPS websites against downgrade attacks, and which greatly simplifies protection against cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,1 and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

  The HSTS Policy[2] is communicated by the server to the user agent via
  a HTTP response header field named "Strict-Transport-Security". HSTS
  Policy specifies a period of time during which the user agent shall
  access the server in a secure-only fashion.

In order to make this work, the HSTS settings should be removed from your browser, this is different per browser.


Using different algorithms to slow down GPU password cracking I have some job related files I have already compressed with 7Z.

I have protected each with  good 10 character passwords consisting of upper, and lower cases, numbers and special characters.

And I have enabled header encryption of the filenames.

I am not yet concerned about the physical security of my system or side channel attacks, but I have heard that GPUs are getting faster at bruteforcing even complex passwords.

Another lesser concern is that the implementation of AES in 7Z might be vulnerable.

But what if I encrypt the files with another symmetric cipher?

My theory is that such a setup keeps me secure even if an adversary succeeds in bruteforcing the outer envelope or exploits a weakness in 7Z's implementation of AES.

What's your take on the following method:

7za a -p -mhe myarchive.7z myfiles

gpg  --output myarchive.pgp --symmetric myarchive.7z

I have read about meet in the middle attacks, but so far I understand the risk, it's only an issue if the adversary is able to reduce the key space by trying to decrypt key1 and key2 simultaneously.

But will this be an issue if the outer envelope doesn't give any clues as to how the next layer is encrypted?

Using a second layer of symmetric encryption prevents the secret data from being revealed if only a single layer is broken.
However, I don't think this is the smartest way to counter potential massive GPU brute-forcing attacks - what actually helps against them are three things:

use an encryption scheme that incorporates a key derivation function

the encryption should use a salt along the password. Chosing a salt value from a good PRNF with enough entropy or directly from a good hardware RNG is paramount.

ensure the password is recursivle hashed multiple times, as often as possible to not make the encryption scheme impossible. This considerably slows down brute force attacks.
PBKDF2 provides all of the above features, but scrypt (which I would recommend over the other if you are that concerned over the security of your data) adds the additional one:

the hash function used to derive the keys should be relatively efficient to execute on a general purpose computer, but difficult to execute on specialized hardware (ASIC) by using a serial, non-parallelizable hash function that needs a lot of RAM to work.

So, I would look out for a good (read: used by others already with good reviews) open/free source implementation of an encryption program using scrypt. AFAIR GnuPG only supports PBKDF2, which is pretty good, but not as good as scrypt, which is its main deficiency.


Feeding PBKDF2 to SRP verifier creation There is an older game that solely uses UDP to communicate, and I wanted to add password authentication to the game to facilitate things like experience points and rankings.  To this end, I decided to go with an implementation of SRP-6a communicated over UDP using an extension of the existing game protocol, and I ended up using cocagne/csrp on the game client side, tunneled through the game server, and mozilla/node-srp on the authentication server side, slightly modified as to produce the csrp-compatible HAMK follow-up response.

It has worked reasonably well so far, however I am not a fan of how the verifier is stored at rest, as it appears that in the process of calculating x the inputs are only hashed once before turning into the verifier v, see here.  I have suggested that we  change this library function to suit our needs (since it's reasonably small and already in-tree) and use something along the lines of PBKDF2.  However I am getting (understandable) push-back from another developer about touching code of this nature, good intentions and all that.

It was suggested instead that perhaps the user's password itself undergo PBKDF2 hashing before being passed in as a password to the verifier creation and user challenge functions.  That way, we do not have to modify any code in the csrp library itself.  Is this a valid approach?  Or is there another bear-trap waiting to snare us if we do this?

For what it's worth, the complete protocol document is here, so if I'm making any other sorts of snafus it'd be nice to know.

The password in SRP is actually a shared secret of (possibly) low entropy. It can be the "password" as the human user understands it, or anything that is deterministically derived from the password. In your case, yes, using a password hashing function such as PBKDF2 is a valid approach. It has the following caveats:

PBKDF2, like bcrypt and other good password hashing functions, requires a salt. The salt is very important. Without the salt, the attacker could optimize attacks to a large extent; namely, he would have to pay for the PBKDF2 step for only one user (if he has several stored hashes for several users to crack). The point here is that the client and the server must use the same salt for a given user, so the client must know that salt somehow. But the salt must still be specific to each user (and changed whenever the user changes his password as well), so you cannot simply hardcode it in the client code.

So you need to store the per-user salt on the server, and to convey it to the client as an initial authentication step. In SRP, the client first sends a message containing the user name (I) and a value that does not depend on the password (A). The server responds with the user-specific salt (s) and another message (B). You should send also in that server-to-client message the extra salt needed for PBKDF2.

Alternatively, you may replace the hashing step in SRP with PBKDF2, but this involves modifying the protocol and the implementation libraries, which is probably not a good idea. It is simpler and altogether safer to add an extra PBKDF2 step.

It is tempting to reuse the same salt as the one specified by SRP (the one called s in the protocol specification). Though this seems cryptographically safe here (the two salt usages being somewhat "separate" with all the PBKDF2 between them), this sort of things is known to be a matter of subtlety, and, there again, having an extra, independent salt is the safe, cautious method.
PBKDF2 employs many iterations in order to slow down attackers. But it slows down normal users as well, so you cannot crank up the iteration count as high as you wish. You should set up as high as you can tolerate, given the load and computational power of the involved computers, and the limits of the user's patience.

In the case of integration with SRP, as with any other PAKE protocol, the brunt cost of password hashing is on the client side. So the appropriate iteration count depends on the client computer. If you have multiple clients then you must adjust to the least powerful computer that is still supposed to be able to connect. This point is especially crucial to Web-based client, with JavaScript, because JavaScript is very feeble for raw computations, severely limiting the number of iterations that you can tolerate. In your case, the client's code uses a C library, so you can have some client-side muscle, but since you are working with an "older game", you must consider that the client may be an "older machine", possibly an "elder machine". There are some perverts out there that still nurse some i486 computers.
You may consider using bcrypt instead of PBKDF2; bcrypt is arguably stronger against attackers with GPU.


When could 256 bit encryption be brute forced? Assuming quantum computing continues to improve and continues to perform like this:

... quantum computer completes 2.5-billion-year task in minutes

is it reasonable to expect that 256 bit encryption will be possible to brute force at some point in the future, and if so, what estimates (preferably from large tech companies, security companies, academics, or government organisations) are available as to when that may start to occur?
Notes

Obviously estimates would be extremely difficult to make, and probably depend heavily on a few key assumptions (and even then it could happen much earlier or much later than predicted), but despite the difficulty of such predictions, some rules of thumb (e.g. Moore's Law) have performed reasonably well given the difficulty of such predictions.

Since the US Government considers 256 bit encryption safe enough to not be broken (by any one outside the US) for a time scale long enough to protect US security interests (last paragraph), we can assume it's a fairly long way away.

Background:

In 1997, the Electronic Frontier Foundation brute forced 56 bit encryption in 56 hours

Most Probably Never
Of the currently known  quantum algorithms, Grover's algorithm is the one which directly affects symmetric ciphers the most. Essentially, for a cipher that a classical computer can bruteforce in time N, a quantum computer can bruteforce it in time square root of N. This means that a 256 bit cipher (which would take at most O(2256) compexity to bruteforce on a  classical computer) could be bruteforced in O(2128) on a quantum computer.
Bruteforcing even a 128 bit key is limited by the laws of physics. As this excellent answer explains, the amount of energy required to bruteforce a 128 bit key is ridiculously large (all the world's resources for 10 years straight, just for cracking one key). So, absent any other significant breakthroughs, bruteforcing a 256 bit key is out of question. In fact, Grover's algorithm has been shown to be optimal, so any further breakthroughs are extremely unlikely.


Best Practice: “One per-user ssh key” or “multiple per-host ssh keys” Possible Duplicate:
  What’s the common pragmatic strategy for managing key pairs?

I was part to a conversation last week about which approach to ssh keys is more “secure”.   Note, that when contemplating “secure” we were trying to factor in human behavior (the most insecure part of any security system).

The ssh environment is primarily Unix/Linux machines (some PuTTY too).  U sers of ssh are “human users” as well as “automation accounts” that are used to execute scheduled tasks/scripts that require scp/ssh to copy files or execute remote commands.

In attempt to come up with a best  practice for our users, we are contemplating the following recommendations:

“one ssh key per-user” - The user generates a single key pair and submits the public key to our automated process which copies the public key to the user's authorized_keys file on hosts where the user is allowed to login.  The user is instructed to use the same pass-phrase protected private key on all hosts that they use as an ssh client.  This approach results in one key-pair for each user.

“multiple 'per-client-host' ssh keys” -  Users should generate a ssh key pair for each SSH client.  The user submits the public key to an automated process which copies the key to authorized_keys file authorized_keys file on hosts where the user is allowed to login.  This approach results in “u x c” key pairs; where “u” is the number of users and “c” is the number of clients.

In our discussions we've noticed advantages/disadvantage for each approach.  For example: the “one ssh key per-user” approach has the advantage of impressing on the mind of the user the importance of their only key as well as the ability for us to audit the presence of the user's one public in audits of authorized_key files.  On the other hand, the “multiple 'per-client-host' ssh keys” approach has the advantage of allowing audits of authorized_key files to determine the user and the client machine that is able login – which seems particularly useful for understanding types of access that non-human accounts  (run  scripts which call SSH/SCP) have.

I'd be very interested in hearing what has worked well for people on this forum.   Thanks in advance.

I recommend you adopt the "one ssh key per user" model.  It is easy to use for end users, simple to explain to users, and is likely to meet the security requirements.

Ease of use is very important.  If a security mechanism is too hard to use, people will find a way to bypass your security mechanism.  An easy-to-use, pretty good security mechanism is far better than a hard-to-use security mechanism that is in theory highly secure (because in practice, if is hard to use, it probably won't be as secure as you expect once people find a way to bypass the security mechanism so they can get their work done).

I think "one ssh key for client machine, per user" is a bad idea.  It sounds like a mess.  Frankly, it sounds like IT run amok, in the sort of way that gives security a bad name and makes people hate IT departments.  You mean I have to generate a separate SSH key for each client, and manage them all?  All for an amorphous security benefit that isn't clear?  Ugh!  I would hate to be in charge of selling this to users.

I suggest that think of these kinds of decisions in terms of "compliance budget". Your employees will put up with a certain amount of annoying compliance mandates (e.g., security requirements) imposed upon them.  Up to a point, they'll follow these mandates.  However, if it gets to be too much, eventually they'll get annoyed and just do whatever they have to do to get their work done, even if it violates all security principles.  Therefore, imposing too many requirements or too much inconvenience can be counter-productive to security.  So, before imposing any kind of security requirement or security-related inconvenience on users, think very carefully.  Imagine that you have a very limited budget for imposing mandates.  Is this the best item to spend your limited "compliance budget" on?

On a related note, I think the benefits of "one ssh key for client machine, per user" are pretty minor.  I don't understand why anyone should care all that much what accounts I can log into with my laptop, vs my desktop.  Is this just micromanagement?  Who cares?  It's me, either way.  If you trust me, you trust me, no matter which of my machines I'm using, right?  It's not clear to me that this is such a big deal that you'd make your users lives harder because of it.

P.S. You mention something about managing what privileges non-humans have.  I didn't quite follow what that was referring to.  You mentioned scripts that call SSH/SCP, but who is invoking those scripts?  If it's a person, then presumably that person is authorizing the activity, right?  If it's not invoked by a person, then I'm not clear on how that would even work (in my experience, such scripts don't have access to your SSH private key, since they don't know your passphrase and aren't attached to any ssh-agent session that would let them access your SSH private key).  I don't know if I'm missing something important in that statement.


I've found security vulnerability in current linux distribution. What next? I've installed ubuntu server 12.04 on VM two weeks ago.
I've created regular snapshots.
XXX time ago I've noticed unusual activity and I've found that a backdoor was installed into my server.
One of backdoored files was sshd. Ive then analysed the logs and found the host which connected to my server in the first place (using my account password). The same method I've extracted from backdoored sshd worked for accessing the root account of attacking host. I've found significant amount of infected hosts (analysing attacking host's logs). And I've  compared the running software. I believe I've isolated the daemon that is vulnerable.

In normal situations I would just format the VM and create a new one (I was using it just for development) but it had the latest stable ubuntu 12.04 linux. (14.04 was released days after I've created the VM) However this seems like a serios vulnerability by the number of infected hosts (and some other sensitive data) and by the fact that my server was running the latest version with all security updates and it still got hacked.

And to get to the question - What should I do next?

(I've got all the snapshots (before infection, after that), access to a lot of infected machines, and an infected server VM part of some kind of botnet that scans and infects other hosts, and some knowledge what other activites it does)

PS: Its not heartbleed as my server's openssl version is :
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr  7 20:33:29 UTC 2014

And the service I believe is vulnerable has no known vulnerabilities.

PPS: How can I check if this is known exploit?

To report a security vulnerability in an Ubuntu package, please file a
  bug, or contact security@ubuntu.com.

http://www.ubuntu.com/usn/


Principally, is input type="text" instead input type="url" a security problem for "website" form fields? I have a simple HTML-PHP-CSS contact form (no JavaScript) with some trivial fields sent via PHP's mail() function. One of the fields is "website" field in which a user should input a website domain (if relevant).

If I add to the form field with input type="url" it obligates users to add a protocol prefix such as http:// or https:// to any website domain or full URL.
Most users don't even think about adding a protocol prefix and would get an error for lacking it and the form won't be submitted without it (some users might not understand the error) so accessibilitywise I have figured that I shouldn't use input type="url" at all and should find another kind of input field to ask for a website domain.

I thought about changing type="url" to type="text".
Perhaps there are some security considerations if one takes that approach.
Principally, is input type="text" instead input type="url" a security problem for "website" form fields?

The type of the input field is not a security feature but merely a usability feature, i.e. it allows early checking of value and might offer already constrains when entering the data in the browser. The server must still validate that the input conforms to the expected type since it is easily possible to bypass the browser based verification or not use an browser at all to submit the input.
Based on this, it is not a security problem to specify type text instead of type url for the input field, but might merely be a usability problem. It gets a security problem only when the server side application blindly assumes that the input will only be of the specific type, i.e. blindly trusts client input based on the wrong assumption that the browser will check it properly.


How can I inspect/audit an Android phone if it's vulnerable to CVE-2012-4221 (or any other?) I want to create a guide (or app) to audit devices and determine if the hardware or software is vulnerable to attack.

Given an arbitrary phone, what process should I do to determine if outstanding patches / vulnerabilities exist?

Or asked a slightly different way, are all the patches exclusive to Google, or are there 3rd party drivers must I inspect?

There are multiple facets to this question.

Phone vendors will typically push patches at their leisure. So part of the question becomes "who is your software vendor?" and "are you running a stock image?" This will determine if there is updated software available.
If in doubt, you can collect proof of concept testers on the internet to attack mobile phones with. This is spotty at best, because not every vulnerability lends itself well to packaging as a risk-free auto-pwn site. The Android Vulnerability Suite that WoJ linked will be helpful with this.
If you are looking at Android as a ecosystem, you'll need to tangle with app permissions and app updates. Apps can introduce vulnerabilities as well, and occasionally updates cannot be done (I've had this happen due to picture overload).
For hardware, it will be a little more esoteric. You'll have to pull in information from the internet about handsets and compile that into your guide. Luckily for your guide (and unluckily for your users), hardware exploits are harder to fix in production, so it should turn into a simple comparison once you find a reputable source.


Can any dangerous file(Virus, Trojan, Malware, etc) cause harm inside a zip or rar? I am using Windows 8.1 pro with Mozilla Thunderbird for my email requirements.

I have my Thunderbird set to auto download all email attachments, however upon runnning a Virus scan I am seeing many .exe, .zip and .rar files flag up as Viruses - Which I then tell my AV to delete.

As these .exe, .zip and .rar files have only been downloaded to my HD, can they do any damage just sitting their?

To my knowledge I must atleast execute them (.exe)or uncompress and double click(.zip, .rar), but perhaps I am wrong.

Firstly I would like to explain differences between Viruses, Trojans and Malware.

Malware - is the short form of Malicious Software. It is basically a software written to cause damage or infiltrate computer systems without the owner informed consent. It is general term used to represent various forms of  intrusive, hostile and annoying code.

Virus - is a software that copies itself and spreads without permission or knowledge of the owner. Viruses do not spread via exploiting vulnerabilities (the ones that do that are called Worms). The only way viruses are supposed to spread is with the host - at least in their rigorous classification. Let say that a virus has infected a file, now if the owner moves the file to any system, the virus has thus chance to spread and survive.

Viruses can be classified into the following sub-categories:

Resident type: which one executed becomes memory resident(and waits
for some triggers such loading of other program). It the infects
other programs and so on.
No resident type: once a virus is executed, it will search for files it can infect.Then    after infecting them, it will quit. When the infected program is run again, it will again find new targets and so on.
Boot sector, which spreads via boot sector and Multi partite type with several types of infection mechanisms.

Trojan - is a kind of malware that appears to the user to perform a function but in fact facilitates unauthorized access to the system. Moreover, they are quite different from viruses. They are not self replicating unlike viruses.

So in general a virus cannot  execute itself, unless it has the cooperation of the operating system or software bugs or the user intervention.

If the operating system allows files to be executed automatically because of their name or location (for example an email attachment) then a virus can masquerade as a legitimate file and be executed by the operating system without the user authorization. This used to be the default behaviour in early email clients.

Also, if the operating system is not patched or specific software has errors that a virus can exploit to run its code, then a virus can start itself.

So to answer your question: Yes you can infect your machine by downloading and storing malware on your hard drive without executing.


Why does Chrome send four browsers in the user-agent header? I am using Chrome in linux with Version 51.0.2704.63 (64-bit). I recorded a HTTP request of Chrome and here is part of the recording:

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36

Why does Chrome send four browsers in the user-agent field? Is this a countermeasure to obfuscate the browser version?

Presumably you mean the following four:

Mozilla/5.0 (X11; Linux x86_64)

AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/51.0.2704.63
Safari/537.36

most Web browsers use a User-Agent string value as follows:

Mozilla/[version] ([system and browser information]) [platform] ([platform details]) [extensions].

Mozilla  is a byproduct of browser wars.
AppleWebKit/537.36 is the platform used by your browser.
Chrome/51.0.2704.63 is your browser
Safari/537.36 was added for historic reasons, where Safari was treated differently.

You may wish to also read this history or this SO post


Is this SSO design secure? We're working on an SSO implementation that would be used accross domains.  I realize there are proven working models out there like CAS for this but I'm toying with a different approach and I want to get feedback from you all here to see if this is secure or not.  The basic premise is that we don't want to use redirects if we don't have to and we want the product sites to be able to style their own login pages. This targets IE8+ and modern FF and webkit only. So, without further ado the implementation:

Client browses to product site A.com.  They don't have a session cookie for a.com so the site initiates the parent auth script.
The parent script builds an iframe that loads a page from the auth server on auth.com. Auth.com validates the request based on the referer header and if the referer isnt trusted then responds with x-frame-options:DENY and/or a frame busting redirect.
The script on this page (the framed script) does an ajax request to auth.com's server asking for an SSO 1 time token (1TT).
The client doesn't have an auth.com cookie so this is rejected, and the iframe script tells the parent script to build an auth form using window.postMessage (and the parent script validates the origin) to communicate since it is cross domain.
The user enters their credentials, and hits submit.
The credentials get passed from the parent script to the framed script via postMessage again, and the framed script uses them to login to auth.com, receiving both an auth.com cookie and a 1TT.
The 1TT is passed back to the parent script.
The parent script passes the 1TT to A.com's server.
A.com uses the 1TT to get the user info from auth.com's server via a private internal API, and auth.com invalidates the 1TT so it can't be used again.
A.com returns a session cookie for A.com to the client, and now the client goes about its business on A.com.
Then the client browses to B.com, but again has no session cookie for B.com.  The parent script is executed again, which creates an iframe again pointing to auth.com. The iframe script requests a 1TT from auth.com, and since it has a session cookie for auth.com this time it gets one.
The 1TT is passed from the iframe script to the parent script to B.com's server which uses it to get the user from auth.com and issue a session cookie for B.com.

My main concern is at step 2. Is this a solid way to prevent malicious framing?  What other security vulnerabilities is this susceptible to?

Edit: All sites and scripts will be loaded HTTPS.

There's not really enough information in your list (as hard as that is to believe, with 12 steps and all) to properly answer, but as you mentioned in your comment above - this is pretty close to the StackExchange model.

With that in mind; have you considered running your own OpenID Provider? The protocol spec looks pretty close to what you're after. This is also a well-tested model, so a lot of the concerns have already been well-solved. OAuth may be suitable, but it's designed around limited access tokens - don't know enough about what you're doing to say which is more appropriate.

Coming back to your model - what you've specified looks ok, though as written there's a mix of 'model' stuff and 'implementation' stuff that makes it a bit tricky to analyse. You're relying on the referrer, but it looks like in this scenario, faking the referrer will only log a client in to a different site they would have access to anyway. You are depending on referer though - maybe just load the frame with a GET request including the referrer?

You're also relying on the ability to pass info back and forth between frames; you may want to consider using an interim page on auth.com instead (i.e. forward user to auth.com, if user already logged in there, POST back to https://B.com with 1TT). Using iframes complicates things (What if you're already in a frame? You're relying on the browser here to 'break out' successfully - could this be subverted by messing with the DOM?). You may be able to make this secure, but it's a complicating factor - and the enemy of good security tends to be overly-complicated schemes.


Is Cloudflare Flexible SSL PCI Complaint I am wanting to use Stripe to take donations on a website.

I understand that Stripe takes care of most of the PCI compliance but requires you to use Transport Layer Security (TLS) so that they make use of HTTPS according to their website.

My question is, since the flexible SSL option on Cloudlfare is not end-to-end, does it still count? I'm trying to understand if I should/am required to buy an SSL cert when Cloudflare can get my site to say it is HTTPS?

Please distinguish what is required from what is recommended in your answers, as I am trying to understand my options, if any.

Thank you.

No, Flexible SSL does not meet PCI requirements.  Flexible SSL (emphasis mine):

  Flexible SSL encrypts traffic from Cloudflare to end users of your
  website, but not from Cloudflare to your origin server.

which conflicts with PCI DSS §4.1 (emphasis mine):

  Use strong cryptography and security protocols to safeguard sensitive
  cardholder data during transmission over open, public networks

You would need the Full SSL option from Cloudflare to be PCI compliant:

  Full SSL mode provides encryption from end users to CloudFlare and
  from CloudFlare to your origin server. This requires an SSL
  certificate on your origin server. In Full SSL mode, you have three
  options for certificates to install on your server: one issued by a
  Certificate Authority (Strict), one issued by Cloudflare (Origin CA),
  or a self signed certificate. It is recommended that you use a
  certificate obtained through Cloudflare Origin CA.

A self-signed certificate won't cost you anything, and CloudFlare's Origin CA is also free and tries to simplify the certificate management.


HTTP HEAD and its security versus operational uses Most security advice I see recommends turning off HTTP Methods like TRACE, OPTIONS, HEAD etc. So now I have turned off most of these options on my web server and leaving only GET and POST options that can be returned. The question is, now some my applications are using HEAD and some users are hitting errors doing stuff in the application. Checking the logs revealed some HEAD requests coming from the user end. I am suspecting that it's because my server has stopped responding to HEAD so the connection has dropped. My question is, is HEAD really that not safe as I read that it also has it's legitimate uses? or should I just tell my application developers/project manager to change their code?
thanks.

HEAD is not dangerous in itself, and it does have legitimate uses. The problem is with Java EE. It has a way to set security constraints  using web.xml files - but  those are only applied to GET and POST, not to HEAD. This means that it is can be possible to bypass authentication using HEAD. There is more information about this and other issues in this paper on penetration testing by the SANS Institute.

Whether this particular issue is applicable to your application will obviously depend on what application server and other security measures you are using.


Is it realistic to only need to remember the one password for the password manager? Is it possible to only remember the master password to the password manager and still be safe? For example you must also know the password to log in to the computer (and possibly the password for full disk encryption) before you can access the password manager. Multiply this for each device.

If you backup your password database then you probably need a password for it too (especially if you’re using a cloud based service, such as Google Drive or Dropbox, for the back up). Also if you have multifactor authentication enabled, you probably need to remember the password for your phone too (if using app such as Google Authenticator).

Is there a better way, or am I misunderstanding something? Is it really possible to only need to know the password to the password manager?

Possible? Yes   Realistic? No

I set my Windows login password to be the same as my FDE password. A controversial choice, but I don't see any major risks with this.

If you have FDE then in theory you can use a password manager with no master password and still be safe. However, most people (and I include myself) don't feel comfortable with that. So that's two passwords as a minimum.

There are some passwords I don't want to put in my password manager, e.g. PINs for bank cards. So I have to memorize them.

I also find there's a few passwords you need to have memorised for practical reasons. One example is my Apple AppStore password. Even with touch ID I find myself typing it enough that I need it memorised. You can't paste into that password field, and it's modal, so you can't switch between it and the password manager.


Dataflow diagram - how far do I need to drill down? I'm trying to create a DFD for a threat modeling exercise.  How much detail should I get into?

The SDL Threat Modeling guidelines state that I know that my DFD needs more detail when there is still a trust boundary in the DFD.  Suppose there is a trust boundary between the datastore A and process B. Since there's a trust boundary, I know the DFD is not detailed enough. How can I go deeper, deep enough that no trust boundary is left? If I drill deeper into the process B and decompose it into smaller parts, will it always be possible to eliminate the trust boundary?
I have CRUD Operations on a database in my dataflow diagram, do I need to create 4 distinct dataflows to accomodate the needs or can I mark the dataflow with "CRUD Operation"?

1) I recommend starting with the diagram you have, and expanding it only when or if you find an ambiguity, a place where there's an additional boundary, where you have to ask "how does this work" to understand an attack or defense, etc.

I don't know what this refers to: "The SDL Threat Modeling guidelines state that I know that my DFD needs more detail when there is still a trust boundary in the DFD".  I owned those guidelines for several years, and I don't think that they said that (while I was responsible.)  Could you add a link?

2) Are permissions on each CRUD operation always the same?  If you have to expand on them to clearly communicate how the software works, then a diagram that shows the separate operations is a helpful communication tool.

Fundamentally, the work you do is supposed to help you understand, communicate and analyze effectively.  If there's work that someone ("the SDL TM guidelines") is telling you to do, and you don't think you need to do it, perhaps do a small experiment.  Then either you'll be surprised, or discover that in that instance, you don't need to go a level deeper.


Decentralized online shopping service Would it be possible to create an online shopping service like Amazon (or Silk Road) but also to make it decentralized so there would no main server users would have to trust with their data?

I imagine p2p approach could work here, although I have no idea how would you maintain integrity of distributed data...

Anyway, is it possible? If yes, how would you do it?

take a look at distributed hash tables, magnet links and the bit-coin protocol.

I guess it is most certainly possible, but the complexity would easiely reach that of a larger rfc. too large to be discussed here.


Comparing the MD5 hash to a modified word document and reverting it to original So i wanted to make a quick small test on comparing hashes between a word document and a small modification inside the document and then revert the changes back to original and check all the 3 hashes. Of course the original and the modified document hash will be different but why is it that when i changed the document back to how it was originally ended up having a different hash when they have the same context?

As others have pointed out in the comments, a Word document is more than just the visible text you see.  Various bits of metadata (such as last modified time, or 'track changes' history) are stored within the file.  If even one bit of one byte were changed, the hash would be completely different.

If you wish to find out which bits have changes, you can compare the original against the modified-then-changed-back copy with a tool like the unix "cmp" (compare files) command, which will tell you the byte location of the furst difference.

Or, break out your favorite hex editor to examine the bytes in each file, and you will find your non-visible change.

Also, as others pointed out, your case is particular to Word (and other meta-data-storing file formats).  If you tried this experiment with a flat ascii text file, you would see the changed-back file have the same hash as the original.


JavaScript encryption for websites delivered via IPFS I would like to encrypt user data in JavaScript in a browser before it gets sent out for storing. I read that this is generally a bad idea but considering the following points at least most of the arguments should be dismissed:

The website is delivered via IPFS. Therefore all its contents can be trusted, nobody can inject malicious code or modify it.
The website is running in a browser in a sandbox environment without extensions, e.g. chrome with incognito mode and all extensions disabled.
The data is sent to IPFS (which is also used for retrieving it later) so nobody can inject or modify it.
For encryption SJCL "the only example of a trustworthy crypto library written in Javascript" is used.

Does this finally allow us to use easy JavaScript encryption or are any remaining attack vectors that I do not see?

Well, one issue until very recently (i.e. last week!) was that implementations of Math.random() in most browsers were, frankly, rubbish. Both V8 (the Javascript engine behind both Chrome and NodeJS) and Spidermonkey (the Firefox engine) used PRNGs with too short periods, and there is evidence to suggest that IE and Edge also have broken PRNGs. This means that if there are any calls to them from anything in a layer that relies on them, there is going to be a limited set of possible results. Now, this can still be a lot of results (about 590 million, for the V8 case), but that is a lot less than the ideal 2^132 (5,444,517,870,735,015,415,413,993,718,908,291,383,296).

This means that any attack has a much higher chance of success - intercept data in transit, and then attack offline. Might take a while, but AES is fast on modern processors, and computers are cheap.

Other issues with this could be: how can you ensure that there are no extensions in use? The browser is out of your control. How can you be sure that there aren't undiscovered flaws in IPFS? Security professionals tend to prefer systems that have been subject to a lot of attacks, and not broken, to new systems that haven't been tested as much. Even if the mathematical theory is perfectly sound, is the implementation correct? One typo or incorrect addition could result in a massive problem - see Heartbleed.

There are also problems with other parts of the browser infrastructure that can affect some types of in-browser crypto. The FileWriter interface was deprecated, meaning that anything larger than the browser memory can't be reliably decrypted (there is no sensible way to write it to disk - oddly enough, FileReader works fine for encryption). Browser support for encryption operations is lacking - Windows and Linux can use native calls for AES nowadays, on modern processors, but it would take work to make browsers able to do the same.

We're getting there, but it's not yet a solved problem. If IPFS stands up to scrutiny, the browser manufacturers implement improved randomisation sources, and so on, it'll be close. The extension problem doesn't seem likely to go away though - people seem attached to their adblockers, and probably don't want to trade security through not having any extensions turned on for adverts!


What should I know to prevent relay attack on NFC? I am doing thesis on "NFC relay attack" in my BSc last year. I have studied 10-15 papers and learned the basics of NFC and relay attack. Still I am no where near to understand how relay attack is performed on NFC and how the protocols work in NFC. What should I learn to know how the Relay attack is performed and how the NFC protocols are related to the attack?

I would stop focusing on 'relay' and do more research into MITM or man in the middle attacks. A relay is essentially just a MITM. Also initially I may even back off of NFC and just study MITM attacks on something that is more thoroughly documented, such as regular MITM over tcp.

When ever I am having trouble wrapping my head around a particular topic I try and create a lab to accomplish this. Research how to implement MITM attacks, specifically with NFC. As you work through that problem you will become intimately familiar with the concepts of the attacks as well as the protocols involved in NFC


Do I have an SSH password? I have an Ubuntu server hosted on DigitalOcean, I have been using SSH keys since the very beginning. (You can chose for it to be setup before the server instance has even been created). So I have never logged in remotely with a password.

I just checked my logs, and as expected there are hundreds of login attempts. I know I can install something like fail2ban, but I was just wondering if there actually is a password for it? I have never set one up, so I just assumed it would only be possible to login with an SSH Key.

How can I check this? If there is one, is it possible to just disable it?

but I was just wondering if there actually is a password for it?

Yes. SSH uses your system users (that's the whole idea of it, to allow users to remotely access a systems account), so there is a password for it (stored in /etc/shadow)

  If there is one, is it possible to just disable it?

Yes. You can (and should, as you are not using your password as you don't even know it) set PasswordAuthentication no in your SSH config file (/etc/ssh/ssh_config for global, ~/.ssh/config for user specific config). Afterwards you need to restart SSH for it to take affect (sudo /etc/init.d/ssh restart)


How do I keep the PDF files in OneDrive secure? I need to store multiple PDF files with sensitive information in OneDrive (consumer, not business version). However I am worried about the security risks in doing so.

I could secure the PDFs with a strong password with AES256, but given the scenario that OneDrive gets compromised and my documents are leaked, it would only be a matter of time before someone can eventually crack the PDF passwords and read the contents of the PDF files. If a hacker is already in possession of the files, there is no way I can stop him from cracking the PDF password.

So if OneDrive gets compromised, how can I make sure that the PDF files cannot be read by an unauthorized person?

If bruteforce or dictionary attack is your concern, you can defend against this by ensuring that the key derivation is suitably computationally intensive to make it infeasible for an attacker to crack the password, while leaving it reasonably convenient for you to decrypt them.

For example, KeePass allows you to store files in password vaults. It's primarily a password manager, but the vault file format is also suitable for files. When creating the vault you can specify the number of rounds for key derivation.

Clicking the "1 second delay" button gives you a round count that will take 1 second to compute on your current machine; multiply this number by however many seconds you want it to take. If you pick a round count that takes ten seconds to compute on your system, even attacker with ten thousand times your computational resources could only try a thousand passwords per second, which isn't really a lot if your password is suitably complex and non-dictionary.

If you're looking for a more traditional option, consider using 7-zip, as it performs key derivation using using 219 iterations of SHA256 (source) by default.