railo-server.xml config and password

[Brad Wood]

In railo-server.xml, the root <railo-configuration> tag in this file appears to store the server admin password and default web context password as attributes.  On one of my servers, the attribute default-password exists, but on another server, it's called default-pw.  Can anyone help clarify the difference between the two?  If I want to manually set the passwords by directly editing the file, which attribute should I use?

Thanks!

~Brad

[Igal @ getRailo.org]

if I were you I'd launch a new instance of Railo Express and set the default password there, then check which attribute was saved in the xml file.

other methods are of course to search the source code or wait for someone else (read "Micha") to answer it.

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/railo/9b8a5251-ac1b-480c-b2d3-7c1e89a2e4ed%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Igal Sapir
Railo Core Developer
http://getRailo.org/

[Brad Wood]

Good call.  A search of the code appears to show what's going on.  Looking in ConfigWebAdmin.java, in the updateDefaultPassword() and setPassword() methods I see references to both "password" and "pw" as well as "default-password" and "default-pw".  

It appears that "pw" and "default-pw" are the currently-used attributes, and that "password" and "default-password" are still only checked for compatibility.

I think that answers my question for now.  Micha, please correct me if I'm wrong and feel free to add any commentary on why the attributes were changed.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

You received this message because you are subscribed to a topic in the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/52473EC7.3080809%40getrailo.org.

[Igal @ getRailo.org]

most likely your assessment about keeping the old attributes to maintain backward compatibility is correct.

that's what I thought just that I wasn't sure which will be the current attribute without checking.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CALbQ1okGpVH6fWhaWQwrnMcdjMo0KXT6NVLk8VfdDjFhrCKxSw%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Brad Wood]

One final bit of this thread for anyone finding it later on google.  The password and default-password attributes store a reversible encrypted pass, whereas the new pw and default-pw attributes store a one-way hash. (SHA-256, 5 iterations).  That makes perfect sense why Micha deprecated the old attributes-- he tightened down security by switching to hashed passwords and needed to be able to tell them apart from the old encrypted ones.

Here's an interesting idea-- add a salt to the hash such as the Railo's server ID.  The good news is, it would make rainbow tables MUCH more difficult to use against hacked passwords.  (each server would need it's own table generated)  The bad new is, config files couldn't be copied between servers without re-hashing the password.

Thanks!

~Brad

[Michael Offner]

That is perfectly right, "password" is the old reversible and "pw" the new one way encryption, Railo is reading both but of course prefer the new one, when updating the pw, the old get removed and only the new get stored.

Why not using cfadmin to set/change password?

Have in mind that the XML can change at any time without warning.

We could do a security level in admin with the warning that the config no longer is portable, a other idea we had for some time is to store the XML as serialized java object (ObjectOutputStream) encrpted what make it extremely hard to read and nearly impossible to update outside Railo.

Micha

Michael Offner

CTO The Railo Company Ltd

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/e9840dfc-75ad-4187-86ad-c7730517994d%40googlegroups.com.

[Brad Wood]

Why not using cfadmin to set/change password?

I am using the Railo CLI to script setup of new machines and the CLI runs in its own server context by default which means <CFAdmin> can't be used.

extremely hard to read and nearly impossible to update outside Railo.

I'm not a fan of that.  I rather like being able to debug settings from the XML file and like being able to manually edit them as a fallback approach.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/E64603EA-6030-431A-A705-DD0A24178B14%40getrailo.com.

[Michael Offner]

Michael Offner

CTO The Railo Company Ltd

Am 03.10.2013 um 08:50 schrieb Brad Wood <bdw...@gmail.com>:

Why not using cfadmin to set/change password?

I am using the Railo CLI to script setup of new machines and the CLI runs in its own server context by default which means <CFAdmin> can't be used.

When you call Railo via cli it still reads the Railo-server.xml with the password set there, so it is possible.

extremely hard to read and nearly impossible to update outside Railo.

I'm not a fan of that.  I rather like being able to debug settings from the XML file and like being able to manually edit them as a fallback approach.

This is maybe true for you, but most people change Railo settings only in the admin.

Do not forget, if we do so, this is a option to enable/disable.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CALbQ1o%3DvUY%2B05rzyg9%3Dp8SRDqQ-OwHMJaA5o2dFRLu_MMaTPuA%40mail.gmail.com.

[Brad Wood]

When you call Railo via cli it still reads the Railo-server.xml with the password set there, so it is possible.

Yes, but it reads the railo-server.xml file that is part of the CLI server context.  I need to reset the password on a separate installation of Railo that just so happens to be on the same hard drive.  Denny and I spoke briefly about running the CLI in the context of an existing install, but honestly the code to read, parse, modify, and write an XML file was far less work at the time.  (3 lines of code)

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/9723856C-38E2-47CF-860B-47FA0B9677F2%40getrailo.com.

[Denny]

On 10/3/13 1:00 AM, Brad Wood wrote:
> *When you call Railo via cli it still reads the Railo-server.xml with the
> password set there, so it is possible.*

>
> Yes, but it reads the railo-server.xml file that is part of the CLI server
> context. I need to reset the password on a separate installation of Railo
> that just so happens to be on the same hard drive. Denny and I spoke
> briefly about running the CLI in the context of an existing install,
> but honestly the code to read, parse, modify, and write an XML file was far
> less work at the time. (3 lines of code)

It would be work to write something to do it on an ad-hoc basis, but you
should be able to set it with a one-liner using the webconfig and
serverconfig arguments I posted. Well, theoretically, ya know. That's
what's /supposed/ to happen, at least. :)

:Denny

--
Railo Technologies: getrailo.com Professional Open Source
Skype: valliantster (505)510.1336 de...@getrailo.com
GnuPG-FP: DDEB 16E1 EF43 DCFD 0AEE 5CD0 964B B7B0 1C22 CB62

[Brad Wood]

Well, it also felt a bit dirty.  I know that running the CLI in the context of an existing install has a very convenient side effect of the <CFAdmin> tag affecting that install, but after your talk of how the CLI was sort of its own stand alone thing, I starting thinking maybe it really *shouldn't* be mooching off another server instance-- especially if I want to override stuff like the text-based error handling or other settings that should only apply to the CLI.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
Did you find this reply useful?  Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to a topic in the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/524D1BE0.2090700%40getrailo.com.

[Igal @ getRailo.org]

making the config file un-portable is a bad idea IMO.

it saves time and sometimes more than that when something goes wrong and you can copy from one instance to another.


Igal

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/E64603EA-6030-431A-A705-DD0A24178B14%40getrailo.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Brad Wood]

I totally understand that.  In fact, that is basically my argument for why I don't want Micha to encrypt the entire config as a binary.  I tend to ride the fence on these sort of things though from a security perspective, which unfortunately is almost always at odds with matters of convenience.  The thing to remember, is that if a config is portable for you, it's also portable for hackers.  The reason being is that hashes with no salt are breakable by the same set of rainbow tables.  Once you salt the hash, a different rainbow table would have to be generated for each Railo instance.  

The min length for the Railo admin password is 6 characters.  No problem, here's a rainbow table of every SHA-256 hash for up to 7 characters.

http://www.cryptohaze.com/gpurainbowtables.php#sha256

Now, the good thing is Micha uses 5 iterations of hashing which means a larger table has to be generated that runs each possible string through 7 iterations, plus Micha added his own flavor of base64 encoding between each digest which means that an off-the-shelf table probably can't be used.  Trust me though, if Railo gets popular enough, there will be some bored hackers some mad GPUs laying around and they will make a table for Railo.  

Enter salt: A table that goes up to a 7 character password is going to be able to crack a decent number of lazy admins who barely snuck by the min password requirements. (And it's about 41GB in size)  Add a salt-- say 32 characters of UNIQUE data to each iteration, and boom you now would need more storage than what exists on planet Earth to generate that rainbow table plus a few million years of time.  And when you get done, your rainbow table would only be useful for a single solitary Railo server.  All because the password wasn't portable.

I know, it all kind of sucks.  I'm fighting for things to be simple because I'm a lazy person, but security is always what makes me do a second take, and I certainly don't want Railo picking up the same reputation ACF is getting for security.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/524D9325.7030304%40getrailo.org.

[Igal @ getRailo.org]

I apologize for not reading the whole thread, so please bear with me during these questions that may have been answered in earlier posts:

is this to protect against someone hacking into the admin via the web? 
or is this to prevent a user from decrypting the data once they get a hold of your source code file?

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CALbQ1okKxx-eRTxiE5vx%2B5K%2BaoiQv6Ub7K0znZovchFr%2BqCNYg%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Brad Wood]

Yeah, I talked a lot.  Denny is rubbing off on me :)  The thread changed topic a bit.  It started off with me simply asking about how passwords are stored, and now it's sort of turned into a discussion of how/if they should be stored any better.

So to answer your question, salting is to prevent someone from being able to reverse engineer the hashed password IF they get ahold of your railo-server.xml or railo-web.xml file.  There are many ways they might get to it.  In Adobe's case, it was remote file disclosure (RFD) in the web admin.  In some cases, it could be bad application code that allows a malicious user to upload a .cfm shell to the server. 

Kind of the same reason you encrypt credit card numbers with a private key that isn't stored on the server anywhere.  You HOPE no one will ever make it into your database, but if they do, you're going to make it so your data is worthless to them, or at least too much trouble to hack.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/524D9902.50804%40getrailo.org.

[Chris Blackwell]

Securing the admin password password isn't very useful if some gets hold of the xml config file they'll be able to decrypt your datasources passwords and potentially gain direct access to your databases... which seems like a much bigger issue to me than someone turning off white space management ;-)

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CALbQ1omDRhp%3DrYbHZ7ArUm-MaXvfZzmN3aJG%2B%3D_Uch%3DJAk02dg%40mail.gmail.com.

[Peter Boughton]

A salted hash does NOT make a config file non-portable.

Why? Because you don't use a salt per server, you use a different salt EVERY time the password is changed, and you store that salt alongside the hash.

Remember: the point of a salt is to prevent PRE-COMPUTED rainbow tables from having any effect - i.e. someone who knows Railo does SHA-256 five times can currently pre-compute the values for a bunch of dictionary words, and have a lookup table that works on every version that uses this new attribute.

Simply adding a salt alongside the hash is enough to prevent this and force them back to standard brute-forcing (which is addressed by using tunable double-digit iterations of an expensive algorithm).

And, of course you don't do any of this by coming up with your own algorithm -- the same way you don't go to a GP to get your teeth looked at -- you pick an existing industry standard algorithm specifically designed for passwords by people that know cryptography inside out.

And if you do a bunch of research on that, the simplest answer you'll find is: go with bcrypt.

Chris wrote:
> if some gets hold of the xml config file they'll be able to decrypt your datasources passwords

Except the databases are locked down to only allow access via the appropriate IP addresses, right? ;)

There are several ways to execute arbitrary code via the admin, so it is a bigger issue than changing settings.

Of course, securing the database passwords is also a good idea - perhaps having databases authenticated via public/private keys, thus making things harder for an attacker. (Might have been discussed here before; not sure?)

It's all about defence in depth; making sure everything is locked down (without being unusable) at multiple levels, not just on the surface.

[Brad Wood]

Good call on simply storing the salt alongside.  I had been thinking of using a salt specific to that server, but you're correct it really doesn't matter as long as it's the same one.  That would in fact make the config portable since it would take the salt with it, and the salt could be a randomly generated GUID at the time the pass was set for all we care. 

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--

Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to a topic in the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CAK%3DoSgiKrHzNVQf108stvON2PiqREBkvGTkHhaG2cFg6nzig9g%40mail.gmail.com.

[Brad Wood]

>  perhaps having databases authenticated via public/private keys, thus making things harder for an attacker. 

I think the main issue with public/private keys are that you need the private key and its passphrase to decrypt the value, which means it needs to be stored somewhere on the server, which means you just defeated the purpose.  

Everyone crucified Linode for storing their public/private key on their CF server that was compromised, but if they truly didn't store the private key's passphrase on the server (like they claimed) then the encrypted CC #'s were in theory as safe as the complexity of their passphrase.  

I don't know how Railo could possibly do that for data source passwords short of somehow asking a user for the passphrase at startup and storing it in memory just long enough to establish the database connection.  That would never work though as Railo need to be able to access the plaintext DB password at anytime to establish new connections, therefore all data necessary to decrypt it must be present somewhere on the server.

This is about where my crypo knowledge starts getting fuzzy which is why, as Peter said, you always try to use proven community libraries for this stuff.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Peter Boughton]

> I think the main issue with public/private keys are that you need the
> private key and its passphrase to decrypt the value, which means it
> needs to be stored somewhere on the server, which means you just
> defeated the purpose.  

Oh, I wasn't talking about storing encrypted details, I meant the tunnelling stuff where you enter a passphrase after OS login then don't need to do further auth, so it's not even something Railo cares about at all.

Not sure if that makes sense or not, it's late here and I'm too tired to think.