Hacker News Reader

Comment by javagram | Hacker News Reader

Apparently it was a password protected spreadsheet.

Which seems like incredible incompetence of the company to accept code in that format in the first place and to not have demanded the password when the first issue arose.

View on HN

On the one hand, yes, that's crazy. On the other hand, an argument can be made that company accept proprietary software in binary form all the time, and this is no different !

Still a good laugh from the sidelines...

> On the one hand, yes, that's crazy. On the other hand, an argument can be made that company accept proprietary software in binary form all the time, and this is no different !

It's a little different if only from a professional dignity perspective, lol. Also, every senior programmer I've ever worked with who makes use of third-party binaries will find a moment to say, "I'll just decompile it if it ever gives us any real trouble!"

Corporations have no professional dignity.

We deliver source to the customer, and include compiled binaries and installers as a (paid) courtesy.

Without the source, the customer loses the ability to switch software contractors, which is against their procurement rules. Even if you don't have the clout of being huge, not controlling the source for business-critical software is basically putting the supplier's gun up to your own head.

Companies that take binary-only delivery have obviously never hired anyone who could tell them they shouldn't do that.

Always get the source, or write it in-house.

Vast majority of companies rely on Microsoft and other proprietary software

I was not discussing computing infrastructure, such as the OS or office productivity suites, but rather custom business logic, that is specific to the company.

I once worked for a company that had a spreadsheet for plant production planning. The spreadsheet was put together by a consultant, but it was not protected - the company adjusted it constantly to maximize productivity at the plant. The consultant made more than the plant manager because he was the only person who understood the spreadsheet enough to make meaningful changes as required, e.g. when a machine on the line was replaced with another having a different capacity.

That's the ethical way to do it. If you give a business everything they ask for in requirements, the end result is probably going to be absurdly complicated for anyone to edit even with documentation, training, and open code.

We offer escrow of our source as an option for our customers who have concerns or policies about mission-critical software. The escrow includes instructions about tooling needed & versions (Visual Studio and others), any third-party (Telerik) or open-source things we use, database creation scripts, etc. A couple have run DR drills where they pulled the escrow, went through the instructions, and produced executables.

If you dump the XML and remove the <sheetProtection password=/> line you don't even need to ask for the password.

Haha really? That is hilariously insecure.

I surmise that the password feature is not meant for true security. It's not protecting the whole document, just the spreadsheet formulas and VB code. Requesting a password for changes to the formulas obviously prevents accidental mistakes, and makes it unambiguously clear that only some people in the enterprise (those who know the password) are 'supposed' to make these edits. Quite clever, as far as it goes.

Makes sense. The software needs to access that code for the spreadsheet to work, so if it was encrypted for example, then the spreadsheet would be unusable unless you know the password

I guess in any case, if you really care about security, you could just encrypt the file separately and only send someone the encrypted binary.

The Torx screw of presentations.

But then again, how would you make it secure? Clearly, the program itself must have full access to the file (formulas and all), otherwise you wouldn't be able to do anything with the spreadsheet (effectively turning it to a pdf). Short of encrypting the entire spreadsheet and sealing the key in a TPM, it's impossible to implement edit protection.

Warning: This being true, it can still be construed as "hacking" no matter how simple it is. Just because the barrier is easy to get over, it doesn't mean you're legally allowed to enter.

This person asserted the spreadsheet was his "work product". Presumably Siemens's lawyers found this convincing enough to be wary of hacking around the password.

I have a different view. Considering the company employed "Person A" to create a spreadsheet, why would it be a violation to employ "Person B" to gain access to it in the absence of "Person A"? The company owns all of the technology and employs all of the personnel involved, no?

Wasn't he a consultant, not an employee?

> company owns all of the technology and employs all of the personnel involved, no?

No, he's a contractor. So what they own precisely should have been defined in the consulting contract.

It may have been perfectly legal for him to password protect the output, much like using an obsfucator - but the time-bomb stuff is fraud any way you cut it.

Nice tip!

I found the following screenshots/guide that shows "sheetProtection" includes "algorithmName" and "hashValue" but not "password" variable... https://www.excelsupersite.com/how-to-remove-an-excel-spread...

About 30 years ago, when I was just a kid, my parents would make me go with them when they went shopping. I would always go wander around the electronics section of the store (I'm thinking of Walmart, specifically) to play with the computers.

At that time, Windows 3.1 was the latest and greatest and is what was running on all of the "display" PCs. Unfortunately, the password-protected screensaver was almost always activated -- meaning you couldn't actually do anything on the PCs.

Luckily, those passwords were easily bypassed! All you needed to do was simply power cycle / reboot the machine. Once it started booting up, you would just hit CTRL-C to interrupt and terminate the "autoexec.bat" file. Next, change into the "\WINDOWS\" directory, and open up some .INI file [0], find the line where the password was set, and delete everything after the "=" sign. Finally, save your changes, exit the editor, and hit CTRL-ALT-DEL to reboot.

The PC would start up and launch into Windows as usual, but without any password protection for the screensaver.

(A slightly older version of myself may have, allegedly, then set his own passwords on occasion.)

[0]: "sys.ini", "windows.ini", something like that.

My recollection is that you can also stop AUTOEXEC.BAT from running by holding the shift key.

You must be crazy to use proprietary closed source software. Oh, wait...

Closed source software prepared and used by only one client is a lot different than distributed and used by many clients.

I'm sure there is a lot of password protected spreadsheets in finance industry.

Yep. If it was me I would hold the supervisors responsible.

Of course you would, developers are always blameless!

Reply on news.ycombinator.com