Nick Hodges

Random Thoughts on the Passing Scene #125

07 Sep

38 Responses to “Random Thoughts on the Passing Scene #125”

  1. 1
    m. Th. Says:

    "Ann Lynnworth of has put together a nice little web app that will show you the CodeRage 4 schedule for your time zone."

    Wheeeee!!!….. :-)

  2. 2
    Luigi D. Sandon Says:

    "Cool things you can do with(out) Delphi 2010 #221 +1": how you can sniff and tamper with Datasnap JSON data. That shows very well a basic flaw of JSON: it is a easily readable protocol, and has no way to protect data integrity/privacy and identify endpoints. And Datasnap does nothing in this regard. Would you ever use it to transmit sensitive data? Of course one could use IPSec (which requires proper network setup, and can only identify machines, not users), or TLS/SSL (which requires a PKI infrastructure to issue and manage certificates for all parties, plus a library to access CryptoAPI or OpenSSL which Delphi has not out of the box, AFAIK).
    Does someone at Emcarcadero understands that in 2010 the problem is not how to transmit data, but how to transmit data securely? Or Delphi "enterprise" target is the Sunday pic-nic booking system only?

  3. 3
    Bruce McGee Says:


    You have a lot to say about the new DataSnap, so you’ve clearly given it a lot of thought. What would you suggest to help fill the gaps? The more specific and constructive the better.

  4. 4
    Luigi D. Sandon Says:

    What I suggest is to rethink DataSnap as a real enterprise solution. Security can’t be retrofitted. Security must be designed built-in. Right now all it can offer is a hook to change the exchanged stream - IMHO it’s not the right design and just mix application-level responsibilities and framework-level ones.
    Also, for the average user implementing security may be a daunting task. It requires a proper knowledge of security itself, and best implementation practices. The time required to properly implement it may be too much, and RAD Enterprise has to justify a €1800 upgrade price.
    Also, security implemented in the wrong way can just give a false sense of security, still exposing sensitive data. Moreover Delphi has no built-in library to ease coding encryption, integrity, authentication and authorization - everything would be left to third party tools or custom made solutions.
    Datasnap needs a protocol where the exchange of security data are separated from but integrated with the application payload, and transparent to the application to ease implementation. It should use standard enterprise class security protocols, be it TLS/SSL which requirese a PKI but works well among different companies - remembering SSL doesn’t work over HTTP only!-, or Kerberos (GSSAPI, whatever) which works better inside company networks and simplify management.
    Datasnap should have facilities to use directories (AD, LDAP) to manage authentication and authorization, because replicating user management in each application may not be feasible, and I’ve seen already enough applications where the authentication was very, very weak. There should be a way to assign permissions at least at the class level, because the same server could be called by different users with different permissions. And again this shouldn’t be handled at the application data exchange level, Datasnap needs a built-in way to exchange user credentials automatically and verify them against the proper servers. It should have management tools to easily deploy and configure those settings.
    When Datasnap used DCOM, although the implementation wasn’t improved since the 95/NT4 days, it could take advantage of MS-RPC security facilities. But when it was reimplemented over dbExpress, security was totally overlooked. IMHO, in 2010 that’s no longer acceptable. Companies face high security risks, and deploying a solution without taking it into account is today a commercial suicide. What data can you exchange without protecting them nowadays?
    If all the "cool" thing Delphi can show in 2010 is how to marshal a date value across the wire in an easily readable and tamperable with format, well, I’d call it Delphi Inprise edition, not Enterprise. And I feel a cold - not cool - shiver thinking about whoever will exchange sensitive data that way, unaware of the implications.

  5. 5
    Nick Hodges Says:

    Luigi –

    You do realize that you have total control over the data stream, and that you can build a filter to encrypt the stream anyway that you want?


  6. 6
    WDS Says:

    My Ideas for Developers ,Blog Repply #1
    HTML interface development .
    HTML interface development needs updates for
    dinamic presentation of its content and
    more better documentation with examples of
    how to get the teory done .

    With component TWebBrownser in set on form ,
    some features are required for the workflow .

    1.Full ("offline") HTML resource support .
    __that plus option of encrypted HTML text resource for
    prevent and preserve the application structure "ID".
    –With automatically of encrypt\decrypt feature for
    no programmer encryption tasks.

    2.Just like point and click ,functions for simple
    ideas tasks that works on (Call) and (Get It Done) .
    __some functions like:
    –LoadHTMLError(res:THTMLResource); //UpdateAll
    –LoadHTMLIndex(res:THTMLResource); //UpdateAll
    …and others if interested for complexity

    Integer or String value for the encrypted HTMLResource .
    -BRCC32 for store.
    -THTMLResource to get encrypted content .
    –IDE interface must to supply its information .

    Thanks .

    "" ideas that’s more than two cents ""
    "" credits for fame and glory ""
    "" Delphi Programmer ""
    [WDS < (Hell Inside)]

  7. 7
    Fabricio Says:

    "You do realize that you have total control over the data stream, and that you can build a filter to encrypt the stream anyway that you want? "

    Seems what he’s asking is: it’s STILL not done YET? Data security is part of any midtier protocol and must be part of DataSnap development process (even if is to show how remove it!!).

    So he wants components to fill that gap. To authenticate on the AD, to authorize, to encrypt and this being pieces on the DSnap dev process.

  8. 8
    Nick Hodges Says:

    Fabricio –

    I see what he wants. I’m just making sure that he understands what is available.


  9. 9
    WDS Says:

    -BRCC32 for store.
    -THTMLResource to get encrypted content .

    BRCC32 as a result of a .RES file .

    THTMLResource as a after compile the now encrypted
    HTML text .RES file

    that when open your program on notepad
    no HTML text are vivible for read .

  10. 10
    Fabricio Says:


    "I see what he wants. I’m just making sure that he understands what is available."

    Since 2010 is out, there’s not much to do. BUT(there’s always a ‘but’), you can aggregate take feedback from the n-tier around the world that’s use Delphi and do a casting of "what’s missing list" for the next DataSnap release. I don’t use anything from DataSnap actually, except TClientDatasets (which have a historical connection with it).

    Even better, with that list, you can create (internally) a multi-tier application with the( all - or just the most importante) bells and whistles in information security. With that made, you can attack the points which generated most effort and try to create tools (components, apps, you name it!!) to reduce the time and coding - at the same time, developing an step-by-step process on how to get done secure middleware software on the time projected and on the value budgeted….. (pun intended) ;-)
    Like the procedures things on the last documentations…

  11. 11
    Fabricio Says:

    I learned a thing or 2 about information security on this blog -
    It’s very pleasant to read.

  12. 12
    Luigi D. Sandon Says:

    "You do realize that you have total control over the data stream"
    It looks Embarcadero don’t really want to understand. As I already wrote, security can’t be retrofitted. It *must be designed built in*. Yes, I can encrypt the stream. What does Delphi offer out of the box for encryption? Where do you store the keys? How do you generate and exchange the session keys? How do you get, pass along and check user credentials? How do you authorize a function call or a callback? How do you check for integrity? How many Delphi developers are proficient in implementing those security features on their own properly? What’s the risk to expose confidential data unintentionally because of blindly using a framework with a flawed design? Would you like Delphi applications being blamed because of their inherent insecurity in the high risk world of today? Or the market is already so little it would go unnoticed?
    Implementing proper security is much more than calling crypt() and decrypt() on a stream, maybe using keys stored in clear text inside the application or the registry! A hook may be good for compression, but it is of very little use to implement secuity but the lowest one.
    The very fact that you think a simple hook to intercept the stream is enough, explain that security was never considered as a fundamental feature of your remoting solution. But any real application moving sensitive data can’t work without it.
    I know I can implement it myself. I can implement my own remoting framework as well. The question is why should I spend 1800 euro to upgrade our "enterprise" licenses when all it has to offer are some database drivers I can get for less, and a remoting solution that lacks basic security features to be usable? What’s the appeal of the ent sku? Should I just buy the pro, if I have to implement everything myself?
    Frankly, I understand you need to sell Delphi and thereby sing a "magnificat" about any new feature. But what should I tell my management to justify the upgrade expense? "We got a new technology, see, I can marshall and pass along a date! Cool! But I can’t ensure you 1) the date I sent is the date that was received 2) it was me to send that date 3) who sent the date has rights to send it 4) no one but me and you saw that date." If I told my friends who left Delphi and moved to other technologies - and they are many - that the cool new thing in Delphi is I can marshal dates and move them over tcp or http, I would make them laugh out loud for several minutes. Touch is cool, but what if I have to code a kiosk application and have to protect the data exchange?
    I am very sorry Embarcadero does not understand what Delphi needs to become a real *enterprise* tool. The market in 2010 is very different from what it was in 1995. The sooner you accept it, the sooner Delphi can offer the needed features - otherwise it will just cage itself to small standalone applications and some C/S ones - if that’s your target IMHO I’d get rid of the sku segmentation and just sell one version only.

  13. 13
    David Heffernan Says:

    Oh please pay attention Nick. Instead of trying to find out what Luigi is talking about by asking more questions you could just read what he said in comment number 4. Your comment about "you can just encrypt the stream" is shockingly naive. I place it up there with your comment about not being able to avoid UAC elevation dialogs if your exe has setup in its name (clue: manifest your exe AsInvoker).

  14. 14
    Dusan Majkic Says:

    > Ann Lynnworth of has put together [plain common sence]

    Thank you Ann. Thank you very much!

    E9o, please note that "2:30PM PDT" seem to me as stardate from captain’s log - completly useless.

  15. 15
    Bruce McGee Says:


    We agree on a couple of things. I think Delphi should ship with a high quality and up to date encryption library. I also think DataSnap should include both simple encryption and key exchange plug-ins that use this library. The fact that these are implemented as plug-ins doesn’t bother me at all. For completeness, a tutorial on using SSL with ISAPI DataSnap servers would probably be useful, too.

    I can’t speak to authentication using AD or LDAP. I don’t have any objection to having this functionality as long as it doesn’t force any additional overhead or implementation details on my apps that don’t want/need it. If that’s the case, I can see an argument for Embarcadero offering this out of the box as well. Especially if there’s a lot of demand. If you make QC requests, I’ll vote for them.

    As I mentioned before, I like that DataSnap (finally) uses a non-proprietary protocol that can be consumed by non-DataSnap clients and isn’t tied to any specific platform or operating system (COM dependencies are gone!). I just watched a CodeRage session where PHP and JavaScript clients were written to take advantage of a DataSnap server’s REST interface. Sweet.

    As far as I’m concerned, any support for someone’s favourite authentication services can not interfere with this "openness".

  16. 16
    Bruce McGee Says:

    Interesting. I thought excluding an encryption filter for DataSnap out of the box was an oversight. In his CodeRage session, Adrian Andrei suggested it had to do with export restrictions.

  17. 17
    Nick Hodges Says:

    Bruce –

    I doubt very much that we’ll ship an encryption library in the box. The export restrictions are just too risky.

    There are numerous third-party solutions out there — including the TurboPower LockBox project.


  18. 18
    Bruce McGee Says:

    Too bad.

    I hope you aren’t restricted from publishing example DataSnap filters that use strong encryption.

  19. 19
    Bruce McGee Says:

    Speaking of LockBox, the Delphi 2010 compatible version was posted to the SongBeamer site.

  20. 20
    Nick Hodges Says:

    Bruce -

    You fine community member types can go to town with it. :-)


  21. 21
    Luigi D. Sandon Says:

    It’s a bit funny people think about DCOM as a fully proprietary protocol, while it is built upon an implementation of DCE/RPC which is an open one. More or less, it allows COM calls over DCE/RPC. Security is mostly handled at the RPC layer. But DCOM is overly complex to use properly, is not interoperable and MS moved (almost) away too. I really hoped about an improved Datasnap to remove DCOM, but not at the expense of removing security and manageability.
    I agree that a remoting library should not require a directory service to work, but if it aims to become an enterprise solution it should offer it as an option. Otherwise deploy in large organizations could become a nightmare - or not possible.
    I’d prefer JSON/Rest support to be implemented as a bridge, instead of being the native implementations. I do not like them. They are born in a webserver/javascript based world, and IMHO they are not the right general solution, especially for applications moving more data than the average web application.
    "export restrictions" looks really like an excuse, like SOX compliancy some time ago. Most restrictions were removed recently, IIRC. For example now Apache offers setups including SSL, which were not available previously. Don’t know how many customers they have in North Korea, Iran, Syria or Sudan.
    Anyway, they could have implemented pluggable support using weak, exportable encryption that could be later changed to use stronger encryption. But regulations also forbids the export of authentication and authorization technologies?
    IMHO, it’s the dbExpress inheritance the cause of this oversight. While coding dbExpress, they didn’t have to take into account security. It was the database client library to handle and protect if needed the communication channel, and it was the database engine to handle authentication and authorization - transparently. When they moved dbExpress to the middle layer, they didn’t understood the channel now became unprotected. And the easily human-readable JSON/Rest protocol just makes it worse.

  22. 22
    Luigi D. Sandon Says:

    LockBox is becoming really old - security is a moving target - it’s not enough just to recompile an old library to remove warnings and add support for a new datatype. For example, available LockBox RSA key sizes are now too small for some applications, and IIRC it lacked some newer encryption features. Right now we are using SecureBlackbox which is mantained.
    Also, if Delphi developers instead of coordinating to mantain the library at SourceForge just start their own forks they really don’t help at all to develop a "standard" encryption library for Delphi.

  23. 23
    Luigi D. Sandon Says:

    "I doubt very much that we’ll ship an encryption library in the box. The export restrictions are just too risky."

    It looks MS likes risks, while Embarcadero doesn’t

    C’mon, find better excuses… or hire better lawyers. :)

  24. 24
    Bruce McGee Says:


    Legal conspiracy theories aside…

    What do you use for n-tier apps? I know you mentioned DCOM before.

    If there was a reasonable encryption filter for DataSnap and a plug-in to use AD/LDAP, would that make you feel more comfortable?

    Which begs the question; What would you consider to be a reasonable encryption filter?

  25. 25
    Fabricio Says:

    The problem with encryption is not only encryption itself, but key management too.

    His DCOM talkings is about the use of DCOM as an easier(?? really don’t know) way to authenticate using as Ad/Ldap out of box.

    About an reasonable encryption filter: it must something you can use single key algorithms and/or public key ones, depending of the requirements of the application.

    Suggestion: think of security not as a tool, but as a process (or procedures, as you call in the docs). Single key crypto algorithms are a subprocess on how to use. Public key ones, another.

    And make the classes extensible, so we and you can create/plug implementations of the "filter" (it’s still a filter? I’m using the name loosely now)….

    DataSnap is a remoting PROTOCOL on itself now, since it’s not DCOM based anymore. And protocols are about processes and standards - it needs a process to do encryption over-the-wire (and on that process a subprocess to manage key).

  26. 26
    Luigi D. Sandon Says:

    Bruce, right now I am using DCOM to implement n-tier solutions, including the old DCOM based Datasnap. I can’t move to the new one as long as it does not offer strong security.
    A reasonable encryption filter? Today most implementations moved to AES for symmetric encryption, (3)DES is not enough secure, Windows Kerberos AFAIK still uses RC4, but WEP demonstrated how it could be easily misused.
    Anyway, there are already security standards like Kerberos, GSSAPI/SPNEGO (which allows to establish what is supported) and TLS/SSL which usually can offer both authentication and data protection and are not Windows only - I would not reimplment the wheel, I’d use standard, proven technologies.
    Usually inside a company network where Kerberos is already supported it’s easier to use it, while if cross-company communication is required maybe TLS/SSL is a better choice although it requires certificates deployment, but it does not require a common trusted server.
    Datasnap should instead implement its way to set permissions on published interfaces - not all users are created equal :)

    As Fabricio says, one of the issue is how to properly manage keys. The strongest algorithm is useless if keys can be easily retrieved by anyone who can access the system. Kerberos uses the KDC, while Windows has facilities to store certificates in AD and locally, accessing both directly is possible but not really "RAD" right now. Anyway a "vault" or "wallet" to store keys securely is needed, or all the infrastructure fails.

    DCOM can use AD to authenticate and authorize users - also has support for impersonation and delegation (the server code runs in the security context of the caller - useful when there are already established ACLs on external resources).
    It’s much easier to create a AD group, assign it AD users, and then set permissions on DCOM objects using it, than having to re-implement user management at the application level and having maybe to keep it in sync with AD or the like. Try to run DCOMCNFG and see what you can do, although an application can implement its own security checks if needed (some interfaces to implement).
    Datasnap could anyway offer a local user management facility if a full directory service is unavailable or if a simpler approach is preferred. If no secuirty is needed, just assign everyone-full access rights.

  27. 27
    Bruce McGee Says:

    I was thinking more along the lines of a simple key exchange using something like a combination of RSA (compromised?) and AES. No vault required. Something useful (at least to me) that would make a good example filter.

    I’ll leave it to someone else to make a filter for security services. I don;t need anything like this right now.

  28. 28
    Luigi D. Sandon Says:

    How do you store private keys? How do you control application access to the keys? Diffie-Hellman can be used to exchange session keys without using RSA, but if you have to authenticate the endpoints and sign the messages you need something alike - and you have to protect the keys somehow.

  29. 29
    Bruce McGee Says:

    Generate key pairs at run time, so they would be stored, but only in server memory. However, I don’t know the best way to perform the exchange. Any references?

  30. 30
    Luigi D. Sandon Says:

    1) you need a good random number generator to create the keys. You don’t need asymmetric key pairs if you generate them at run-time.
    2) One of the best ways to exchange the key is the Diffie-Hellman algorithm I cited before.
    3) If the connection lasts enough, keys should be changed sometimes.
    4) Take into account it could be not possible to exchange a new key for each data exchange because computating it may require too much time.
    5) You still have the problem to check whom you’re exchanging keys with - or man-in-the-middle attacks can be performed ;)

  31. 31
    David Heffernan Says:

    Here’s a thought. Why not hire a couple of people who are already experts in this arena? Get them to teach the key people already in place what the issues are and what the standard solutions are. Most important is that you don’t re-invent the wheel and that you follow industry standard practices. It also would be wise to make it easy to use native platform services where they are available. That will grease the skids with the IT managers who run the networks.

  32. 32
    Bruce McGee Says:

    The advantage of using RSA for the key exchange is that I don;t have to implement Diffie-Hellman myself.

  33. 33
    Luigi D. Sandon Says:

    I’ve seen this comment on StackOverflow: "How does encryption go "long in the tooth"? It still works, right? An algorithm is an algorithm. :-)"

    It’s now really clear people in charge of Delphi at Embarcadero have no clue about security. And that’s dangerous. I already said security is a moving target. Algorithms may be broken, have undiscoverd flaws, or keys become insecure due to their size, both because of increased computational power and improvements in cryptoanalysis. Algorithms once regarded secure now are not. 3DES and MD5 are no longer secure. AES is increasing the key size, and SHA is increasing the hash size as well. RSA is using larger and larger keys, hoping noone finds a demonstration of Riemman hypothesis :)
    When designig security, one also has to take into account how long the data will be valid. If I transmit a credit card number with one year validity, I must ensure it’s not possible to decrypt it before it expires. If I am transmitting data that can be valid for years, I have to be secure enough encryption can’t be broken in the foreseable future.
    David Hefferman is right: hire a couple of experts and have them explain you what security really is.

  34. 34
    Bruce McGee Says:

    Luigi. Feel free to include your perspective in the SO thread.

  35. 35
    Luigi D. Sandon Says:

    Done. Although I thought it would deserve a post here too, because I am afraid there’s the wrong perception of security at Embarcadero - while it’s becoming an important part of application development whenever the application manage sensitive data. If Delphi does not help its developers to implement security features properly, it risks to see its market shrink more and more - because it can’t address 2010 application needs.

  36. 36
    Luigi D. Sandon Says:

    I’d suggest this book: - the first edition is now downloadable for free, and although a little outdated is a good starting point - if read taking into account "security is a moving target". The only drawback is you won’t look at your credit card as you did before… ;)

  37. 37
    Nick Hodges Says:

    Luigi –

    Since you are so much smarter than I am on all of this, maybe you can explain to me how the fact that an existing algorithm, though perhaps broken, will actually become "long in the tooth"?

    Again, thanks for all the great information. You are really smart.


  38. 38
    Luigi D. Sandon Says:

    AFAIK to "become long in the tooth" means to "become very old". If so, an algorithm gets old because even if the algorithm still works as intended, the time to extract the plaintext from its cyphertext becomes perfectly acceptable for an attacker. At this point it becomes dangerous, thereby useless and "old". Using it’s not security - it’s fake one.

    I am not smarter. I was just humble enough and took the time to understand what my applications needed and needs to implement proper security to work in today’s world. I work for a software house part of an aereospace company. My Delphi applications have to work in a sensitive environment.
    Believe me, if I didn’t care about Delphi I would not be here trying to persuade you to improve it. I’d just use some tool that already implements what my applications needs.
    Sorry if sometimes I look angry, but it’s very hard to understand some positions, like the "export risk" while other tools implement those features already and I never saw Gates jailed for helping North Korea to deliver .NET encrypted rockets.
    I can understand your resources are not enough to cover each aspect and you have to give priorities - just say so. Dismissing features like Unicode (how long did you take?), 64 bit or security with a "won’t do" - or "wait as long as we can" or "we have a very basic implementation, it’s enough" - as if they were not important does not help Delphi image, because the perception is you don’t care about your customers needs at all, and make it look an old, simple tool to code trivial applications - unless one spends a big effort and/or buys several third party libraries to fill the gaps. At least we had a roadmap!
    Look at this scenario: you have now touch support. Great for POS/kiosk applications. But those installations usually work in a very unsecure environment. Machines and cables are usually very easy to reach - they are not servers secured in a datacenter. Or they just use trivial data, or you have to secure them somehow. But you get a tool that can be great to implement one side, but totally overlooks the other. And unlike fancy controls, Delphi security libraries do not spring up all over the Internet.
    IMHO, that’s not smart at all, because it lowers Delphi value a lot, and developers may move to other tool to get a more inclusive solution - and unluckily they exist.

© 2014 Nick Hodges | Entries (RSS) and Comments (RSS)

Your Index Web Directorywordpress logo