alexkus

For my Comp Sci degree I wrote a regexp/automata library. It allowed you to create/modify/load/save/execute NFAs, and the same kinds of functions for a basic regexp language (character classes, ., Kleene star *, ?, etc) by first converting the regexp into an NFA (with epsilon transitions) as each regexp operation maps to a small NFA so they can be bolted together (with epsilon transitions).

You could then (attempt to) convert NFAs into a DFA using Myhill-Nerode theorem to determinise it; I say attempt as it was possible to make it consume huge resources if you gave it the right/wrong kind of regexp. It also did minimisation and a few other bits and bobs.

To say this gave me a good understanding of regular expressions is an understatement, and once you understand the basics then all of the parts of more complex regular expression languages become a lot easier! That was my enlightenment.

One crucial difference:-

One system is an utter pain to actually cash out of if you start pulling in decent revenues.

The other one is...oh.

It may not be hacked. It may just be returning 403 for everyone anyway.

Don't forget that most symmetric encryption algorithms can be used as a hash. Just encrypt a known plaintext (usually all NUL bytes) using the password as the key.

Hmm, if that was me (as the server programmer) I'd return a purposely different checksum[1] in the error message and then (internally) flag anything that was then submitted with that 'incorrect' checksum.

What you do with these flagged entries is up to you:-

a) Delete the scores after an hour or so (giving the chance for the user to check things)

b) Only display those scores to the user that logged in

c) Flag the entire account as 'cheat' and ban it after a few dodgy submissions

etc...

1. i.e. expected hash is hash(real_salt+data), supposed expected hash (returned to client in error message) is hash(cheat_salt+data). You obviously never return the real expected hash.

> Hamilton didn’t talk a lot about AWS’s custom-built storage, but he did share one tidbit. The densest storage servers you can buy commercially today come from Quanta, and a rack full of them would weigh in at about three-quarters of a ton. “We have a far denser design — it is more than a ton,” Hamilton said.

Interesting. For reference; a Backblaze pod is 4U and weighs 145 pounds, so 10 of them in a standard 42U rack would be 1450 pounds = 0.715 (short) tons (or ~648kg).

Ironic given that Bitcoin grew out of the idea of a 'Proof-of-work' token that was proposed as a FUSSP itself.

Was the offer withdrawn after 10 seconds?

...but actually just renamed to a .nomedia extension and left on the HDD?

I'm guessing the GP was referring to the fact that Levison didn't update Lavabit to prefer ciphers that provide perfect forward security. Here is his own admission on the subject:-

" When I was designing the Lavabit encrypted storage feature in 2004, it simply wasn’t possible for an attacker to intercept and decipher a large number of SSL connections in real time. This assumption was presumed true even if an attacker managed to gain access to the SSL private key. The situation has obviously changed. Network tools now decipher SSL connections efficiently, and servers are fast enough to make this attack a reality. A theoretical weakness became practical. I missed that development. More importantly, I failed to update the Lavabit SSL configuration to prefer ciphers that provided perfect forward secrecy. "

Source: http://arstechnica.com/security/2013/11/op-ed-lavabits-found...

That's the major difference between hubs and switches.

As a generalisation: hubs just push everything received from one port out to all ports.

Switches are cleverer in that they only direct the right traffic (that may include broadcast traffic) to all ports.

Of course, there are cheap 'switches' that are nothing more than hubs.

Probably because the memory allocated just happened to contain only NUL bytes where that specific cleanup function pointer is stored whenever it was run in testing.

The point is that a targeted malicious attack would try and ensure that those bytes were not NUL and that it ended up calling malicious injected code on the target server.

True, but it's easy to email the people involved to suggest lines of questioning for future public (and private) sessions.

This may also work for those "outside the UK".

(It works for me whilst the original link doesn't as the BBC thinks my IP is in .ch despite me being less than a mile from the Houses of Parliament.)

Excellent, some very sensible/esteemed members on the ISC.

> I have seen heroin ruin people's lives and I wish with all my heart that it could be eradicated.

Not disagreeing with you, but I (personally) have seen far more people's lives ruined by legal drugs such as alcohol, tobacco and various painkillers than I've seen from hard/illegal drugs (heroin/crack/cannabis/etc).

ACID doesn't apply since you can't copy a large file in an instant. The copy takes time, in which time the files on disk can change. This isn't the same thing as the server losing power.

VM snapshots, zfs snapshots, etc are the way to go.

Long hours often die out when the compensation (i.e. share options) dries up.

I started off working 80+ hours a week, as did many of the others, and loved it. We all did pretty nicely out of it thanks to share options.

But 10 years later, post acquisition(s), and most people who are still here have families and more life outside work. I work part time so I have a day with my daughter and I officially work 33 hours a week, in a "long" week I maybe work 35 hours and I rarely ever take my laptop home. It's all helped me to be a lot more focused in the relatively short time I am at work.

I guess a lot of it is about experience and, as the saying goes, "Good judgement comes from experience. Experience comes from bad judgement."

Going away for a week long residential course felt like a very long time to be away from my 3 year old. Can't imagine doing that every week. I feel bad about her being at nursery for 10 hours a day (8am to 6pm) whilst I'm at work; luckily that's only 3 days a week as my wife and I only work 4 days each.

Sure, someone on a single machine isn't going to get far, but that's not a great defence to rely upon.

The answer is one of two things:-

Botnets, which most hacking groups will have some access to. Being in control of a modest 10,000 machine botnet reduces that 200 years to about a week, call it 5 weeks if you limit utilisation to 20% of a single core. Expect more of this when bitcoin mining on botnets becomes less profitable.

Also, despite bcrypt() being designed not to be easy/fast to implement on GPUs because of the memory footprint required, GPUs are growing in size and reasonable implementations exist for FPGAs. ASICs would be even faster.

Upping the work factor to compensate for this makes more work for the CPUs at the site that is using bcrypt(). I know of one company that has more cores utilised in performing bcrypt() checks than they do running the HTTP and DB portions of the site.

So do multiple things to make it harder for the naughty people, i.e. hash and then encrypt the result.

Hashing or Encrypting?

1) If you have to choose one or the other then obviously hashing (with a random salt and a relatively expensive algorithm, e.g. bcrypt et al with suitable work factor) is generally the way to go.

But it is still possible to brute force many of the easy passwords from a DB leak of bcrypt() hashes, it just takes a bit of time. From there you get to know that email address X uses password Y, which may open the door for hacking into other accounts where they've used the same passwords.

The people that get fucked over first from a DB leak of hashed passwords are those with weak passwords. A poor hashing algorithm (unsalted MD5, etc) may even expose seemingly "unguessable/random" passwords thanks to rainbow tables.

Even with bcrypt() hashed passwords you should be able to work through a huge portion of the top 100 passwords for all 130M accounts and come out with a huge number of email/password pairs.

Increasing the work factor of the hashing algorithm is a trade off, too high and you'll soon need extra servers just to cope with the extra CPU load of people logging in and having to check their passwords, too low and the hashes are easier to crack.

2) But, why not use bcrypt() to hash the passwords, and then some encryption algorithm to encrypt the resulting hashes?

Before anyone jumps in with it, doing this is not "security by obscurity" because you're not relying on the encryption key remaining secret alone to protect the password.

What it does protect you from is a basic leak/dump of the DB being open access for those who want to try cracking the bcrypt() hashes.

They're left with an initial problem of finding the encryption key before they can even start on the bcrypt() dictionary attack.

Sure it just takes someone to grab a copy of the login code (or wherever the encryption key is being stored) but you've protected yourself from a basic SQL injection attack that could be used to just dump the DB without access to the server to compromise the login code.

Also, hints:-

Why weren't the hints encrypted? (Including having a random n character 'salt' that is prefixed to them before encryption to prevent the same hints encrypting to the same string).

If the hints were encrypted you couldn't use them to help guess passwords.

Even if the passwords were hashed rather than encrypted, the unencrypted treasure trove of password hints would make the job of cracking the passwords much much easier.

Why were the hints even stored in the same table (or even on the same server) as the passwords? (Maybe they weren't and the hackers got both and combined the two datastores.)

Again, if the server was compromised enough that the source for the login code was obtained then the hints would effectively be in plaintext, but you've still protected the hint data from a simple DB dump hack.

First off, I really enjoyed it, well done!

> I can get up to around 110wpm without errors in a general typing test, but because of this constant mistargeting, I was capped around 60wpm with 90% accuracy.

Same here, most other tools measure me at ~130wpm (if I'm nicely warmed up) but I couldn't get above ~65wpm/93% accuracy on the game.

I'd agree with the other comments about a faster progression through the game. I'd like it to quickly move forward to roughly the level I want to be on. Shunt me forward a lot, if I die then shut me back half way from where I was (e.g., 1 > 20 > 40 (died) > 30 > 35 (died) > 33 > 34, etc).

In my ideal 'expert mode' I'd want to be playing so that it quickly finds a level that I can complete a certain percentage of the time but allows me to die a few times on a level before assuming that one was too much for me; some times you get caught out by something random that causes you to fail to complete on a level you'd normally have no trouble on.

Depending on what you use the IP for, asking a third party for your IP address could be an interesting attack vector for a MitM attack.

e.g. you need your IP to tell a remote server to send you something. You connect to the IP address service to ask for your IP, it should return x.x.x.x but it returns y.y.y.y instead. Any connections to any port on IP y.y.y.y get forwarded to a similar port on IP x.x.x.x meanwhile the MitM takes a copy of all of the data going back and forth.

It's not foolproof, and there are a myriad of ways to defend against it, but it's definitely a reason why I wouldn't trust any third party service (even DDG/Google) to get my IP address.

Ah yes, I was getting the various Keying options mixed up in my head:-

http://en.wikipedia.org/wiki/Triple_DES#Keying_options

[EDIT]

It does seem odd though that the passwords are encrypted and not hashed, but the hints are in plaintext. Why didn't they also encrypt the hints? (Rhetorical, the answer is probably just laziness/incompetence).

Even if you do use bcrypt() or similar for hashing the passwords then encrypting the hints would prevent similar tactics being available from just a dump of the table contents.

On the other front, these passwords are all encrypted (not hashed) using 3DES in EBC mode.

Something encrypted with by (single) DES could be broken within 7 days about 2 years ago by some bespoke hardware.

If Adobe have been using the same key for each part of the triple DES key then you can assume that bespoke hardware of several years ago could get the key within 3 weeks (3DES being ~3 times the work of single DES). With advances in technology this is probably down to less than a week.

Let's just hope that they used a full 168-bit key, rather than repeating the single 56-bit key, and that it never gets leaked.

I started with Robot Arena (by SPA Publishing) on the RM 380Z in the late 80s. Where's my last comment about this? Ah:-

https://news.ycombinator.com/item?id=4726828

Exactly a year ago! (And no progress at all on that github repository!)

> High-frequency transmission requires that you have elements capable of transmitting externally at very high frequencies and elements capable of receiving at very high frequencies.

You only need to transmit the carrier at the high (inaudible) frequency, you can receive at any sub harmonic frequency as long as the transmission protocol is designed with this in mind.

So a carrier signal broadcast at 20KHz (within the range of the speakers) but inaudible to most humans can be picked up by sampling at 10KHz (within the range of laptop microphones). The protocol just needs to send each bit twice (or any multiple of two) at 20KHz.

> Current theory: alarm clock designers never marry.

But when they do they may end up with their own alarm clock that is impervious to logic, programming or reason.

For a notional 7am setting our little alarm clock wakes up one of us (a seemingly random choice) usually sometime between 6.15am and 7.15am. Very occasionally it malfunctions and wakes us both up at 3am.

"Move fast and break (other people's) things!" ?

> I also do not understand why a big company would share the same public key across servers?

They might not be different servers, just different IPs. Multiple external IPs may all terminate at the same piece of hardware (Firewall, VPN device, SSL terminator, etc).

For "doesn't use your bandwidth" read:-

  * The public wifi usage doesn't eat up any of the private bandwidth allowance
  * The public wifi is limited to 512kbps but private usage gets precedence (meaning that the bandwidth available for public wifi could be 0kbps at any point in time)