Umbennen einer registrierten Dateiendung *.accdb

Es gibt 17 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Umbennen einer registrierten Dateiendung *.accdb

    hi leute,

    ich habe eine accdb als db in einer anwendung.
    damit nicht jeder user gleich durchblickt und ggfls. mit access selbst in den tabellen rum fuhrwerkt, habe ich die accdb einfach umbenannt und mit einer eigenen endung versehen.
    funktioniert sehr gut. da die daten teilweise noch mit aes verschlüsselt abgelegt werden ist das für mich eine gute lösung.
    nun kam mir die idee ob das wohl so erlaubt ist?
    könnte ja sein ich verstoße hier gegen irgendeinen microsoft lizenz vertrag oder so...
    kann mir das jemand sagen? oder ist das völlig egal?

    *Topic verschoben*
    Gruß Hannes

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    KidRick schrieb:

    kann ich sie einfach zurück ändern.


    das ist richtig, jedoch musst du erst einmal auf die idee kommen, dass es access ist bzw. die datei mmit einem passenden editor durch schauen.
    ich will ja auch nur die "üblichen user" fern halten, nicht die experten.
    wenn einer access hat ist die versuchung schon gleich höher darin rum zu murksen.
    Gruß Hannes

    Meines Wissens dürftes du da keine Probleme bekommen, die Dateiendung spielt bei der Lizensierung keine Rolle.
    Edit: und den "gewöhnlichen" User sperrst Du auf jeden Fall aus, ich seh das immer bei uns was es für eine Panik verursacht wenn jemand ausversehen die Endung .pdf mit was annerem Verknüpft
    "Hier könnte Ihre Werbung stehen..."

    hans im glück schrieb:

    damit nicht jeder user gleich durchblickt und ggfls. mit access selbst in den tabellen rum fuhrwerkt
    Verpass doch der Access-Anwendung ein Passwort - das muss doch genügen, dass 'normale User' nicht unbefugt an den Tabellen herumfuhrwerken können...

    hans im glück schrieb:

    mit access selbst in den tabellen rum fuhrwerkt, habe ich die accdb einfach umbenannt und mit einer eigenen endung versehen.
    Spätestens wenn dann so ein 1337-h4xx0r daher kommt und deine Anwendung dekompilliert, dann isses eh vorbei. Dann kann er nachvollziehen, welche Datei in deinem Programm ordner die Datenbank ist. Hier hilft, wie @VB1963 gesagt hat, ein Passwort.

    @KidRick AES verschlüsselung sichert nur die Vertraulichkeit, hat aber keinen Sinn, wenn die Intigrität eine Rolle spielt. Der "Hacker" kann immer noch hergehen und seine eigenen Daten einfügen. Dazu einfach das Programm decompilen, das Passwort heruasfinden und die Daten manipilieren.
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    Ich glaube, @hans im glück möchte ein gewisses Mass an Sicherheit vor dem DAU erreichen. Dazu ist ein Passwort alleine aber auch nicht das Richtige.
    Der DAU soll ja wahrscheinlich mit dem Inhalt der Access-DB arbeiten im Sinne von CRUD. Das Passwort gewährt ihm aber soweit mir bekannt ist den vollen Zugriff.
    Da können dann auch wieder Datenbankstrukturen zerstört werden.
    Wenn man also nNUR mit Access arbeiten möchte, bleibt wohl nix anderes übrig, als mit einer recht aufwändigen VNA-Programmierung den DAU von anderen als zugelassenene Aktionen auszuschliessen.

    Oder man baut mit VB eine Oberfläche, die genau das erlaubt, was erlaubt werden soll. Ist m.E. der einfachere Weg.

    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    danke für euer feedback!

    ich kanns euch ja schnell schildern:

    es geht um eine verwaltung von zugangsdaten (usernames, accounts, pws)....
    die zugangsdaten an sich werden als aes verschlüsselte strings in der access db abgelegt. der key für die verschlüsselung steht selbstverständlich nicht in der anwendung.
    (genau genommen wird der key auf wunsch in einer key file aufbewahrt (txt file mit wiederrum verschlüsselten string - der key)
    wenn also jmd die access db in *.accdb umbenennt, kann er sehen dass es kategorien usw gibt und sieht die verschlüsselten strings. mehr auch nicht.
    wenn er z.B. ne id ändert knallts halt (wegen relationalem datenmodell) und daher will ich nicht dass er überhaupt auf die idee kommt.

    ich denke das passwort ist kein großer aufwand und würde das ganze noch optimieren. wobei dieses passwort dann doch im quellcode steht (ist aber ebenfalls nochmals eine hürde).
    Gruß Hannes

    @Radinator
    Nee, so gut bin ich nicht. Ist ein Typo, sollte VBA heissen :D :D :D

    hans im glück schrieb:

    wobei dieses passwort dann doch im quellcode steht

    Also, Access speichert das Passwort irgendwo irgenwie verschlüsselt in einer der Datein, die zum Access-System gehören. Die *.accdb wird mit diesem Passwort verschlüsselt. Für ältere Access-Verionen gab es "Passwortknacker", sowas ist mir bei *.accdb bislang noch nicht untergekommen, ist wohl schwer bis unmöglich.

    das würde ja bedeuten, dass ich mit meinem masterpasswort nicht nur die strings innerhalb der table rows verschlüssle, sondern zusätzlich noch die gesamte access db.
    das wäre dann ja doppelt sicher da der, der die db entschlüsselt dann noch wissen muss mit welcher technologie die strings verschlüsselt wurden.
    Gruß Hannes

    hans im glück schrieb:

    die zugangsdaten an sich werden als aes verschlüsselte strings in der access db abgelegt
    Das verfahren des Speichern von verschlüsselten Zugangsdaten ist doch schon 3000 mal überholt worden. Man speichert doch schon seit einiger Zeit Passwörter und Anmeldenamen nur noch als Hashes und vergleicht dann die gehashte Anmeldung mit den Einträgen aus der DB. Wennn Eintrag gefunden, dann gehts weiter.

    Anforderung an die Hashfunktion ist natürlich logischerweise die Kollisionsarmut.
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    Das ändert nix an meiner Aussage. Wenn du Daten sicher speichern willst, dann reicht es nicht aus, sie einfach nur zu verschlüsseln. Wenn der Hacker das Passwort herausfindet, dann kann er die Passwörter wieder herstellen (das mit den PW rausfinden gilt ungefähr auch bei Hashes aber ein 8 oder 12 stelliges PW rauszufinden ist weniger aufwändig, als eine gescheite Hashfunktion zu brechen.
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    Radinator schrieb:

    Das ändert nix an meiner Aussage.




    nur wenn ich passwörter speichern muss (nicht die der anwendung) bringt mir ein hash nichts. ich muss sie ja im klartext wieder zugänglich machen um sie in einer anwendung, auf einer webpage oder sonst wo verwenden zu können.
    das passwort für die aes verschlüsselung ist nicht gespeichert, das ist quasi das einzige passwort das sich der user noch merken muss.
    und meines wissens nach ist aes mit 128 oder 256bit wohl so ziemlich mit das sicherste an verschlüsselung.
    Gruß Hannes

Facebook
Telefonspende